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

34Re: on_fault

Expand Messages
  • Ray Rizzuto
    Feb 14, 2001
      Paul,

      There's no perfect solution to error handling since it depends so
      much on the application. In my case, I am choosing to treat
      transport errors as non-fatal in the belief that they can be
      retried. Application errors (faults?) hopefully don't happen, but
      when they do they probably require manual intervention.

      I think I can almost get the behavior I want with an appropriate
      on_fault handler. I have a few questions/suggestions:

      1) could you give more details on the parameters passed to the fault
      handler? And also what the fault handler can return and how that is
      used? It seems that what it returns is returned to the failed call,
      but I'm not positive.

      2) in one of the examples you provide, you are creating a new
      SOAP::SOM to return from the fault handler:

      use SOAP::Lite
      on_fault => sub { my($soap, $res) = @_;
      eval { die ref $res ? $res->faultdetail : $soap->transport-
      >status };
      return ref $res ? $res : new SOAP::SOM;
      };

      If I could set the fault values in this new SOM, I would be able to
      address errors uniformly after the original call. Or am I
      misunderstanding this code?

      3) in the above code, on a transport error @_ has 2 entries, but the
      second one seems to just have an empty string. Is that the defined
      behavior for a transport error?

      Ray

      --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
      > Hi, Ray!
      >
      > That is perfectly right and I understand it, but for several reasons
      > default value was chosen as die on transport and return fault on
      SOAP
      > errors. You may easily alter this behavior (you may even specify it
      > once for ALL objects in your code with GLOBAL SETTINGS), but there
      is
      > no one-size-fit-all solution.
      >
      > I thought about doing styles, so you can choose for example, die
      > style and I'll install handler for you, or warning style or error
      > code style or whatever, but i think it's too complicated conception.
      >
      > Best wishes, Paul.
      >
      > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
      > > Paul,
      > >
      > > I'd like to be able to handle the transport errors in the same way
      > > as
      > > faulted calls, via the fault methods of the SOAP::SOM returned
      from
      > >
      > > the call. That's why I was trying to create a SOAP::SOM and set
      > > the
      > > string.
      > >
      > > Part of the reason for this is that transport errors may be
      > > transient - I'd like to retry the call later in the application
      I'm
      > >
      > > writing. My app is a gui interface to a problem tracking system.
      > > If
      > > the user is creating or editing a problem report, and the network
      > > goes down, I want them to be able to reattempt the update in a
      few
      > > minutes.
      > >
      > > Ray
      > >
      > >
      > >
      > > --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
      > > > Hi, Ray!
      > > >
      > > > --- Ray Rizzuto <ray.rizzuto@u...> wrote:
      > > > > I'd like to be able to handle all errors from a soap call,
      > > > > including
      > > > > transport errors, after the call completes. I've set the
      > > following
      > > > > fault handler, which almost works except that the faultstring
      > > isn't
      > > > > available after the call to the method:
      > > > >
      > > > > sub fault
      > > > > {
      > > > > my($soap, $res) = @_;
      > > > > if (defined $res && ref $res)
      > > > > {
      > > > > print $res->faultstring;
      > > > > return $res;
      > > > > }
      > > > > else
      > > > > {
      > > > > print $soap->transport->status;
      > > > > $res = new SOAP::SOM;
      > > > > $res->faultstring("transport error");
      > > >
      > > > Here is the reason. faultstring() and other methods are
      readonly.
      > >
      > > You
      > > > may get access to message structure, but you cannot
      update/modify
      > >
      > > it.
      > > > Next version probably will generate warning/error if you try to
      > > > provide parameter(s) for these methods.
      > > >
      > > > > I'm very new to this, so I may be making an obvious mistake.
      > > >
      > > > You may check Error Handling section on
      > > http://guide.soaplite.com/.
      > > I
      > > > prefer 2.k example and in any case you always have access to
      > > result
      > > > of the call through call() method:
      > > >
      > > > print $soap->mymethod(123)->result;
      > > > print $soap->call->faultstring;
      > > >
      > > > Even if call made with autodispatch:
      > > >
      > > > use SOAP::Lite +autodispatch => ...;
      > > >
      > > > print mymethod(123);
      > > > print SOAP::Lite->self->call->faultstring;
      > > >
      > > > Best wishes, Paul.
      > > >
      > > > __________________________________________________
      > > > Do You Yahoo!?
      > > > Get personalized email addresses from Yahoo! Mail - only $35
      > > > a year! http://personal.mail.yahoo.com/
      > >
      > >
      > > ------------------------ Yahoo! Groups Sponsor
      > >
      > > To unsubscribe from this group, send an email to:
      > > soaplite-unsubscribe@y...
      > >
      > >
      > >
      >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Get personalized email addresses from Yahoo! Mail - only $35
      > a year! http://personal.mail.yahoo.com/
    • Show all 9 messages in this topic