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

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

Expand Messages
  • Philip Molter
    ... 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
    Message 1 of 7 , May 22, 2001
    • 0 Attachment
      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@...
    • Meisner, Sean
      Hi Phillip, I find eval blocks to be the best form of error handling Perl provides, for 2 reasons: 1. Client programmers are *forced* to deal with errors. If
      Message 2 of 7 , May 22, 2001
      • 0 Attachment
        Hi Phillip,

        I find eval blocks to be the best form of error handling
        Perl provides, for 2 reasons:

        1. Client programmers are *forced* to deal with errors.
        If one of your methods dies, and the client programmer
        is not catching the exception, the program dies then
        and there, rather than messing up later on because a
        programmer "forgets" to check a return code. Makes
        debugging a lot faster in a language like Perl where
        return values can be (and in code I've been forced to
        deal with, routinely are) ignored at will.

        2. Its a lot more flexible than simple return codes.
        Nested evals, evals around multiple statements that
        can be handled with one error routine, etc. I won't
        go into a ton of detail because as you said, we are
        talking about general programming methodology rather
        than SOAP::Lite specific stuff.

        For the record, although I think this is in no way
        a good basis for forming an opinion on a programming
        methodology, I find exception handling to be the cleanest
        "looking" way to handle errors in an object-oriented
        environment, regardless of language.. but that is purely
        subjective. I use it for its functionality.

        Cheers,

        Sean

        -----Original Message-----
        From: Philip Molter [mailto:philip@...]
        Sent: Tuesday, May 22, 2001 12:15 PM
        To: soaplite@yahoogroups.com
        Subject: Re: [soaplite] Re: error reporting in non-soap served modules


        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/
      • 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 3 of 7 , Jul 20, 2001
        • 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.