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

error reporting in non-soap served modules

Expand Messages
  • rog2@foskett.f9.co.uk
    hello, I am writing an application API which will primarily be availiable on a SOAP server - however I also want to write in in such a way that it can be used
    Message 1 of 7 , May 22, 2001
    • 0 Attachment
      hello,

      I am writing an application API which will primarily be availiable on
      a SOAP server - however I also want to write in in such a way that it
      can be used normally in Perl scripts.

      I have previously tackled the problem of methods returning undef and
      still reporting errors through the use of a DBI type mechanism wherby
      the error code and message is stored back into the object.
      Use would then simply be like 'die $o->errmsg if !$o->getlist();'

      The problem I am now trying to resolve is how to implement such a
      mechanism in a module which may or may not be served from a
      preforking SOAP server.

      Errors are returned with SOAP::Lite by simply dying - however this is
      not really the desired effect when being used as a normal module (ie
      would have to eval every API call)

      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)

      I think the DBI idea would be the best - is there perhaps some way of
      telling when a module is being dispatched by a SOAP server?

      I would appreciate any ideas on an approach to this

      many thanks

      Roger Foskett
    • Meisner, Sean
      Wrapping an eval around code that may die is an acceptable approach to handling errors.. this is equivalent to the try-catch mechanism used in languages
      Message 2 of 7 , May 22, 2001
      • 0 Attachment
        Wrapping an "eval" around code that may "die" is an acceptable
        approach to handling errors.. this is equivalent to the try-catch
        mechanism used in languages like C++ and Java. 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() ...

        Cheers,

        Sean

        -----Original Message-----
        From: rog2@... [mailto:rog2@...]
        Sent: Tuesday, May 22, 2001 7:33 AM
        To: soaplite@yahoogroups.com
        Subject: [soaplite] error reporting in non-soap served modules



        hello,

        I am writing an application API which will primarily be availiable on
        a SOAP server - however I also want to write in in such a way that it
        can be used normally in Perl scripts.

        I have previously tackled the problem of methods returning undef and
        still reporting errors through the use of a DBI type mechanism wherby
        the error code and message is stored back into the object.
        Use would then simply be like 'die $o->errmsg if !$o->getlist();'

        The problem I am now trying to resolve is how to implement such a
        mechanism in a module which may or may not be served from a
        preforking SOAP server.

        Errors are returned with SOAP::Lite by simply dying - however this is
        not really the desired effect when being used as a normal module (ie
        would have to eval every API call)

        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)

        I think the DBI idea would be the best - is there perhaps some way of
        telling when a module is being dispatched by a SOAP server?

        I would appreciate any ideas on an approach to this

        many thanks

        Roger Foskett




        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/
      • 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 3 of 7 , May 22, 2001
        • 0 Attachment
          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 4 of 7 , May 22, 2001
          • 0 Attachment
            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 5 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 6 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 7 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.