Loading ...
Sorry, an error occurred while loading the content.

Re: [soaplite] Re: OO-ish Exception Handling

Expand Messages
  • Paul Kulchenko
    Hi, Arun! Forgot to tell you. With last version you may always write die SOAP::Fault- faultstring( My Error ) on server side, which is the same as die My
    Message 1 of 5 , May 7 2:21 PM
    • 0 Attachment
      Hi, Arun!

      Forgot to tell you. With last version you may always write

      die SOAP::Fault->faultstring('My Error')

      on server side, which is the same as

      die 'My Error'

      but with SOAP::Fault you may also specify faultcode, detail and
      faultactor. It's documented and examples are included in
      My/Parameters.pm. More details later.

      Best wishes, Paul.

      --- u_arunkumar@... wrote:
      >
      > Hi Paul,
      >
      > >> All extended information (and objects also) will be encoded
      > >> inside fault detail element and can be recovered on client side.
      >
      > Can you tell me how exactly do I get my hands on the info encoded
      > inside the detail element, on the client side ? On the client side
      > I
      > am getting a HASH blessed as 'detail' on the client side.
      >
      > Its something like the following when I dump the faultdetail() on
      > the
      > client side
      >
      > bless( {
      > 'Error__Simple' => {
      > '-package' => 'Demo',
      > '-text' => 'Simple Exception',
      > '-file' => 'Demo.pm',
      > '-line' => 41
      > }
      > }, 'detail' );
      >
      >
      >
      > NOTE: The server has thrown an Exception as
      >
      > throw Simple::Error('Simple Exception');
      >
      > and this is after applying the patch that i had mentioned in the
      > previous post.
      >
      > I can directly access the hash values by saying something like
      > $file = $res->faultdetail()->{'Error__Simple'}->{-file};
      >
      > But is this the best way to do it ? Why cant we have helper methods
      > in the 'detail' class to access the info encoded in 'detail'.
      >
      > Best Regards,
      > Arun
      >
      > --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
      > > Hi, Arun!
      > >
      > > > Paul !! if you are listening :-) kindly let me know your
      > comments
      > >
      > > :)) It definitely makes sense for me. That's the reason why I
      > changed
      > > fault handling in last version (0.50) on server side (I think
      > that
      > > now your calls could work, but little bit code on client side is
      > also
      > > required). Next version should bring extended support on client
      > side.
      > > What I have in mind is configurable STYLES of fault handling
      > based
      > on
      > > on_fault method. You will be able to specify how you want to
      > handle
      > > errors, for example:
      > >
      > > die_with_Fault (and SOAP::Lite will die with SOAP::Fault on any
      > > errors)
      > > die_with_string (and SOAP::Lite will die with string message)
      > > die_on_transport_error (exactly like now)
      > > return_transport_as_fault (will report transport errors like
      > > $soap-fault, say Server.Transport or something like this)
      > > something else probably, I'm working on it.
      > >
      > > You may always specify your own on_fault handler if you want, but
      > > styles will simplify fault handling in your code.
      > >
      > > What you suggest can be implemented right now as far as I
      > understand
      > > (but I didn't try it yet for Simple::Error) with coding in
      > on_fault
      > > handler.
      > > I like this idea, but I think your patch is not applicable right
      > now,
      > > because of last changes in fault handling on server side.
      > >
      > > > If you folks think that I am insane saying all this then please
      > > > bear with me :-)
      > > The same thing is true about me :). If you think it's way to go
      > let
      > > me know.
      > >
      > > NOTE! I'm going to Vegas on Interop conference and probably won't
      > be
      > > able to answer my emails promptly, but don't worry, I'll answer
      > all
      > > of them when I'll be back later this week.
      > >
      > > Best wishes, Paul.
      > >
      > > P.S. you may always override make_fault call in your SOAP server
      > > implementation and fix it, at least temporarely :). Best ideas
      > will
      > > be incorporated in main code, absolutely! Thanks, Arun!
      > >
      > > --- u_arunkumar@y... wrote:
      > > > Hi all,
      > > >
      > > > I am planning to implement OO-ish error handling over SOAP.
      > (Using
      > > > Graham Barr's 'Error' module). I initially thought that if I
      > simply
      > > > call
      > > >
      > > > throw Simple::Error("Some Exception on the Server");
      > > >
      > > > then I would get the exception reported on the client side. But
      > > > when I
      > > > actually tried that, to my surprise I was not getting the
      > exception
      > > > reported on the client. (If someone is interested in knowing
      > why,
      > > > then
      > > > let me know I'll explain that).
      > > >
      > > > After a quick peek into the SOAP/Lite.pm and the behaviour
      > > > of thrown Exceptions under a eval block, I was able to discover
      > > > that
      > > > the SOAP/Lite.pm's handle() method was not detecting the
      > throw()
      > > > call
      > > > because it was coded as follows:
      > > >
      > > > die ref $@ ?
      > > > $@ : $@ =~ /^Can't locate object method "$method_name"/ ?
      > > > "Failed to locate method ($method_name) in class ($class)" :
      > > > SOAP::Fault->faultcode($SOAP::Constants::FAULT_SERVER)->
      > > > faultstring($@)
      > > > if ($@);
      > > >
      > > > I had to make the following changes for the exception to be
      > > > detected:
      > > >
      > > > - if ($@);
      > > > + if ($@) or (ref($@);
      > > >
      > > > # normal result
      > > > - return $result unless ($@);
      > > > + return $result unless ($@ or ref($@));
      > > >
      > > > and also insert the following line between the last two
      > > > make_fault()
      > > > calls
      > > > in the method.
      > > >
      > > > return $self->make_fault(ref($@), "$@", $@)
      > > > if UNIVERSAL::isa($@ => 'Error');
      > > >
      > > > The above statement would ensure that all exception classes
      > derived
      > > > from 'Error' would be considered.
      > > >
      > > > (If the above description is confusing I can post the diffs
      > against
      > > > SOAP-Lite-0.50)
      > > >
      > > > With this I am able to get the exception thrown to the remote
      > end
      > > > over
      > > > SOAP. Now I have to figure out a way to rethrow the exception
      > at
      > > > the
      > > > client end using the same exception class. Because on the
      > client
      > > > end
      > > >
      > > > I would receiving only a SOAP Fault and not an exception thrown
      > > > from
      > > > that class. Once this is done then we would have a fully
      > functional
      > > > OO-ish exception handling system working over SOAP.
      > > >
      > > > Paul !! if you are listening :-) kindly let me know your
      > comments
      > > >
      > > > If you folks think that I am insane saying all this then please
      > > > bear with me :-)
      > > >
      > > > Also mind you I am trying to implement this over a TCP
      > Transport
      > > > and
      > > > both my client and server would be using SOAP::Lite. I have
      > really
      > > > not
      > > > considered all the other combinations SOAP::Lite can handle
      > (and
      > > > that
      > > > is exactly why I am posting this on the list, to get people on
      > the
      > > > list to apply this to their situations ..)
      > > >
      > > > With this you can SOAPify any class that handles exceptions in
      > a
      > > > OO-ish style and still have the same exception thrown/caught at
      >
      === message truncated ===


      __________________________________________________
      Do You Yahoo!?
      Yahoo! Auctions - buy the things you want at great prices
      http://auctions.yahoo.com/
    • Arun Kumar U
      Hi all, First of all sorry for buggin you all with all those gory details :-) After going thro the Error.pm code, I realize that none of these patches are
      Message 2 of 5 , May 8 1:24 AM
      • 0 Attachment
        Hi all,

        First of all sorry for buggin' you all with all those
        gory details :-)

        After going thro the Error.pm code, I realize that
        none of these patches are called for in SOAP::Lite

        The problem is with Error.pm and how it handles the
        '-value' attribute and the overloading method value()
        for '+0'. I have sent a detailed mail to Graham (Barr)
        the author of Error.pm, giving the details and a also
        a fix for this. I hope he'll incorporate that in
        Error.pm very soon. (Anyway, I yet to hear from Graham,
        I'll keep u all informed when that happens)

        If someone is interested in the patch then I can send
        you my patch against Error-0.13, off the list.

        Best Regards,
        Arun


        On Mon, 7 May 2001 u_arunkumar@... wrote:

        > Hi all,
        >
        > I am planning to implement OO-ish error handling over SOAP. (Using
        > Graham Barr's 'Error' module). I initially thought that if I simply
        > call
        >
        > throw Simple::Error("Some Exception on the Server");
        >
        > then I would get the exception reported on the client side. But when I
        > actually tried that, to my surprise I was not getting the exception
        > reported on the client. (If someone is interested in knowing why, then
        > let me know I'll explain that).
        >
        > After a quick peek into the SOAP/Lite.pm and the behaviour
        > of thrown Exceptions under a eval block, I was able to discover that
        > the SOAP/Lite.pm's handle() method was not detecting the throw() call
        > because it was coded as follows:
        >
        > die ref $@ ?
        > $@ : $@ =~ /^Can't locate object method "$method_name"/ ?
        > "Failed to locate method ($method_name) in class ($class)" :
        > SOAP::Fault->faultcode($SOAP::Constants::FAULT_SERVER)->
        > faultstring($@)
        > if ($@);
        >
        > I had to make the following changes for the exception to be detected:
        >
        > - if ($@);
        > + if ($@) or (ref($@);
        >
        > # normal result
        > - return $result unless ($@);
        > + return $result unless ($@ or ref($@));
        >
        > and also insert the following line between the last two make_fault()
        > calls
        > in the method.
        >
        > return $self->make_fault(ref($@), "$@", $@)
        > if UNIVERSAL::isa($@ => 'Error');
        >
        > The above statement would ensure that all exception classes derived
        > from 'Error' would be considered.
        >
        > (If the above description is confusing I can post the diffs against
        > SOAP-Lite-0.50)
        >
        > With this I am able to get the exception thrown to the remote end over
        > SOAP. Now I have to figure out a way to rethrow the exception at the
        > client end using the same exception class. Because on the client end
        >
        > I would receiving only a SOAP Fault and not an exception thrown from
        > that class. Once this is done then we would have a fully functional
        > OO-ish exception handling system working over SOAP.
        >
        > Paul !! if you are listening :-) kindly let me know your comments
        >
        > If you folks think that I am insane saying all this then please
        > bear with me :-)
        >
        > Also mind you I am trying to implement this over a TCP Transport and
        > both my client and server would be using SOAP::Lite. I have really not
        > considered all the other combinations SOAP::Lite can handle (and that
        > is exactly why I am posting this on the list, to get people on the
        > list to apply this to their situations ..)
        >
        > With this you can SOAPify any class that handles exceptions in a
        > OO-ish style and still have the same exception thrown/caught at the
        > remote end.
        >
        > Any hints/suggestions on how to have the client rethrow the exception
        > from the same Exception class as the server, would be most welcome.
        >
        > Best Regards,
        > Arun
        >
        > P.S: Paul !! would you be interested in incorporating this in
        > SOAP::Lite.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.