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

Re: error reporting in non-soap served modules

Expand Messages
  • rog2@foskett.f9.co.uk
    thanks sean, ... 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
    Message 1 of 7 , May 22, 2001
      thanks sean,

      > In the case of the example you gave,
      >
      > die $o->errmsg if !$o->getlist();
      >
      > where you are going to "die" on an error anyway, you could
      > just "die" in getlist() and not have to call errmsg() ...

      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.

      Not sure if this is really the best use of the fault facilities SOAP
      provides but it is the only way I can think of writing a dual purpose
      Perl Module.

      many thanks

      Roger Foskett
    • Meisner, Sean
      Hi Roger, ... That s the case where you would wrap the call with an eval block and check $@ immediately following the block. eval { @list = $o- getlist(); };
      Message 2 of 7 , May 22, 2001
        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;
        }

        Hope it helps,

        Sean
      • 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 3 of 7 , May 22, 2001
          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 4 of 7 , May 22, 2001
            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 5 of 7 , Jul 20, 2001
              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.