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

Re: [soaplite] Re: error reporting in non-soap served modules

Expand Messages
  • Paul Kulchenko
    Here is one of the messages that were returned to me due to problems on yahoo. Feature that is described there still should be in the coming version :)) ...
    Message 1 of 7 , Jul 20, 2001
    View Source
    • 0 Attachment
      Here is one of the messages that were returned to me due to problems
      on yahoo. Feature that is described there still should be in the
      coming version :))

      > --- Original message follows.
      > Hi, Philip!
      >
      > > Well, this is all very much getting into programming theory and
      > > away
      > > from SOAP::Lite, but I'm a much bigger fan of the first method
      > > rather
      > > than the eval-if method of error handling. eval'd code just
      > looks
      > You're right, that's not about SOAP::Lite, but interesting to talk
      > about also. Seems like we have three levels of fault:
      >
      > Transport
      > SOAP
      > Application
      >
      > SOAP::Lite on server side wraps Application faults as a SOAP faults
      > and return is to you, but maybe it's not what user want.
      >
      > Here is quote from original Roger's letter:
      > I could perhaps use a DBI approach, returning the error message in
      > the object which the client would then check with another bit of
      > server or client API code - however this could greatly increase
      > network traffic (if server used).
      > Or, I could always return the error message or undef as the first
      > parameter from each method (messy)
      >
      > One of the approaches is to return undef as the result and signal
      > error as a additional info inside an object. It'll also work:
      >
      > die $o->errmsg if !$o->getlist();
      >
      > but will require additional rountrip to get an error info even if
      > it's already here!
      >
      > Two choices are possible:
      > 1. implement errmsg() method locally. It will be used to get info
      > from object and other calls will go remotely:
      >
      > package My; # the same as on remote side
      >
      > sub errmsg { print shift->{errinfo} }
      >
      > 2. use feature that is coming in new version, like autoinheritance:
      >
      > package My::Local;
      >
      > @My::Local::ISA = 'My'; # as on remote side
      >
      > sub errmsg { print shift->{errinfo} }
      >
      > and use in your code My::Local instead of My, but since it's
      > inherited it'll will function exactly as My, only errmsg() will be
      > handled locally.
      >
      > Both approaches should work, second has advantage that you have a
      > choice between local and remote calls. In fact you have a choice in
      > BOTH cases: you can always go remotely with $o->SOAP::errmsg;
      > Hm, I like it :))
      >
      > It might give you an idea.
      >
      > Best wishes, Paul.
      >
      > --- Philip Molter <philip@...> wrote:
      > > On Tue, May 22, 2001 at 11:33:53AM -0400, Meisner, Sean wrote:
      > > : Hi Roger,
      > > :
      > > : > yes but I might want the client/script to deal with the error
      > > instead
      > > : > of dying which is what would happen if the module is being
      > used
      > >
      > > : > normally and not through SOAP::Lite.
      > > :
      > > : That's the case where you would wrap the call with an eval
      > block
      > > and
      > > : check $@ immediately following the block.
      > > :
      > > : eval
      > > : {
      > > : @list = $o->getlist();
      > > : };
      > > : if ($@)
      > > : {
      > > : handle_error;
      > > : }
      > >
      > > Well, this is all very much getting into programming theory and
      > > away
      > > from SOAP::Lite, but I'm a much bigger fan of the first method
      > > rather
      > > than the eval-if method of error handling. eval'd code just
      > looks
      > > so
      > > damn ugly, and most of the time, you don't need to die from
      > simple
      > > object methods. Most of the time, you can just continue and use
      > > errmsg() routines to store error values that may or may not be of
      > > consequence. die'ing just isn't the cleanest looking way to pass
      > > exceptions in Perl.
      > >
      > > Why you use die with SOAP::Lite is because that's the easiest way
      > > to
      > > return a fault. Rather than go through and take a module that
      > > works
      > > perfectly fine with an errmsg() routine and rewrite it to die
      > > internally, just use the facilities SOAP::Lite gives you and die
      > > with
      > > the errmsg(). No one needs to go around changing any modules and
      > > your
      > > code isn't filled with all these nasty-looking eval-if
      > statements.
      > >
      > > * Philip Molter
      > > * DataFoundry.net
      > > * http://www.datafoundry.net/
      > > * philip@...
      > >
      > > 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/


      __________________________________________________
      Do You Yahoo!?
      Make international calls for as low as $.04/minute with Yahoo! Messenger
      http://phonecard.yahoo.com/
    Your message has been successfully submitted and would be delivered to recipients shortly.