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

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() ...

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?

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.

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.

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.

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! Messengerhttp://phonecard.yahoo.com/

Your message has been successfully submitted and would be delivered to recipients shortly.