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

Re: OO-ish Exception Handling

Expand Messages
  • u_arunkumar@yahoo.com
    Hi Paul, ... 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
    Message 1 of 5 , May 7 12:21 PM
    • 0 Attachment
      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
      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.
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > To unsubscribe from this group, send an email to:
      > > soaplite-unsubscribe@y...
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Yahoo! Auctions - buy the things you want at great prices
      > http://auctions.yahoo.com/
    • 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 2 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 3 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.