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

OO-ish Exception Handling

Expand Messages
  • u_arunkumar@yahoo.com
    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
    Message 1 of 5 , May 7, 2001
    • 0 Attachment
      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.
    • Paul Kulchenko
      Hi, Arun! ... 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
      Message 2 of 5 , May 7, 2001
      • 0 Attachment
        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. All extended information (and objects also) will be encoded
        inside fault detail element and can be recovered on client side.

        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@... 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@yahoogroups.com
        >
        >
        >
        > 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/
      • 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 3 of 5 , May 7, 2001
        • 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 4 of 5 , May 7, 2001
          • 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 5 of 5 , May 8, 2001
            • 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.