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

Re: [soaplite] Re: on_fault

Expand Messages
  • Paul Kulchenko
    Hi, Ray! ... Unfortunately not only. It may depend on Server implementation also, though I tried hard to hide these details from you. Several situations are
    Message 1 of 9 , Feb 14, 2001
    • 0 Attachment
      Hi, Ray!

      --- Ray Rizzuto <ray.rizzuto@...> wrote:
      > There's no perfect solution to error handling since it depends so
      > much on the application. In my case, I am choosing to treat
      Unfortunately not only. It may depend on Server implementation also,
      though I tried hard to hide these details from you.
      Several situations are possible:
      1. 200 OK + SOAP message (normal result)
      2a. 500 Server Error + error message (not SOAP)
      2b. 400 Bad Method + error message (not SOAP)
      2c. 510 Not Extended + error message (not SOAP)
      3a. 500 Server Error + SOAP message (Fault result)
      3b. 400 Bad Method + SOAP message (Fault result)
      4. 200 OK + SOAP message (Fault result)

      2c will be handled by SOAP::Lite automatically (you won't see it, as
      well as redirect from server).
      3b and 4 are not allowed according to current spec., though there was
      long debates about using 1 and 4 instead of 1 and 3a.

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

      First, on_fault will be called unless transport returned success.
      on_fault accepts two parameters: SOAP::Lite object and deserialized
      result (exactly as you would get it after $soap->mymethod() call).
      You may return this deserialized result or create your own and it'll
      become the result of call.
      In case you returned false (on_fault(sub{})) result of the call will
      be deserialized message as if on_fault wasn't call at all (no error
      handling).

      > 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?
      No, you're not. You cannot assign it, but you may create new SOM
      object as result of deserialization:

      use SOAP::Lite
      on_fault => sub { my($soap, $res) = @_;
      eval { die ref $res ? $res->faultdetail : $soap->transport->status
      };
      return ref $res ? $res :
      $soap->deserializer->deserialize(
      $soap->serializer->fault('Server.Transport',
      $soap->transport->status));
      };

      print SOAP::Lite->proxy('http://localhost/')->mymethod->faultstring;

      > 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?
      There should be deserialized message (if you got Fault response) OR
      content of the message (if message couldn't be deserialized, for
      example HTML code or some string with error message), so if you check
      and there is not refrence, you can be sure that it's pure transport
      error (and not SOAP Fault).

      Hope it helps.

      Best wishes, Paul.


      __________________________________________________
      Do You Yahoo!?
      Get personalized email addresses from Yahoo! Mail - only $35
      a year! http://personal.mail.yahoo.com/
    • Ray Rizzuto
      Paul, In your list of errors, I don t see the case I m experiencing, which is a timeout: 500 Can t connect to pc-rizzuto-p:9999 (Timeout) In that case, what
      Message 2 of 9 , Feb 14, 2001
      • 0 Attachment
        Paul,
         
        In your list of errors, I don't see the case I'm experiencing, which is a timeout:
         
        500 Can't connect to pc-rizzuto-p:9999 (Timeout)
         
        In that case, what should I get as the second parameter to the fault handler?  In the debugger, @_ has length 2, and print $_[1], but print ref $_[1] returns an empty string.  Is that because the content of the response is empty?
         
        Ray
         
        P.S.  Thanks for the information on using $soap->deserializer->deserialize to create a SOM with the appropriate fault information in it.  I would never have been able to figure that out by myself!
        -----Original Message-----
        From: Paul Kulchenko [mailto:paulclinger@...]
        Sent: Wednesday, February 14, 2001 12:46 PM
        To: soaplite@yahoogroups.com
        Subject: Re: [soaplite] Re: on_fault

        Hi, Ray!

        --- Ray Rizzuto <ray.rizzuto@...> wrote:
        > There's no perfect solution to error handling since it depends so
        > much on the application.  In my case, I am choosing to treat
        Unfortunately not only. It may depend on Server implementation also,
        though I tried hard to hide these details from you.
        Several situations are possible:
          1. 200 OK + SOAP message (normal result)
          2a. 500 Server Error + error message (not SOAP)
          2b. 400 Bad Method + error message (not SOAP)
          2c. 510 Not Extended + error message (not SOAP)
          3a. 500 Server Error + SOAP message (Fault result)
          3b. 400 Bad Method + SOAP message (Fault result)
          4. 200 OK + SOAP message (Fault result)

        2c will be handled by SOAP::Lite automatically (you won't see it, as
        well as redirect from server).
        3b and 4 are not allowed according to current spec., though there was
        long debates about using 1 and 4 instead of 1 and 3a.

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

        First, on_fault will be called unless transport returned success. 
        on_fault accepts two parameters: SOAP::Lite object and deserialized
        result (exactly as you would get it after $soap->mymethod() call).
        You may return this deserialized result or create your own and it'll
        become the result of call.
        In case you returned false (on_fault(sub{})) result of the call will
        be deserialized message as if on_fault wasn't call at all (no error
        handling).

        > 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?
        No, you're not. You cannot assign it, but you may create new SOM
        object as result of deserialization:

        use SOAP::Lite
          on_fault => sub { my($soap, $res) = @_;
           eval { die ref $res ? $res->faultdetail : $soap->transport->status
        };
             return ref $res ? $res :
               $soap->deserializer->deserialize(
                 $soap->serializer->fault('Server.Transport',
        $soap->transport->status));
           };

        print SOAP::Lite->proxy('http://localhost/')->mymethod->faultstring;

        > 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?
        There should be deserialized message (if you got Fault response) OR
        content of the message (if message couldn't be deserialized, for
        example HTML code or some string with error message), so if you check
        and there is not refrence, you can be sure that it's pure transport
        error (and not SOAP Fault).

        Hope it helps.

        Best wishes, Paul.


        __________________________________________________
        Do You Yahoo!?
        Get personalized email addresses from Yahoo! Mail - only $35
        a year!  http://personal.mail.yahoo.com/


        To unsubscribe from this group, send an email to:
        soaplite-unsubscribe@yahoogroups.com


      • Paul Kulchenko
        Hi, Ray! ... Agree. Fixed list: OK Transport + OK SOAP 1. 200 OK + SOAP message (normal result) Error Transport + no SOAP 2a. 500 Server Error + error message
        Message 3 of 9 , Feb 14, 2001
        • 0 Attachment
          Hi, Ray!

          --- Ray Rizzuto <ray.rizzuto@...> wrote:
          > In your list of errors, I don't see the case I'm experiencing,
          > which is a timeout:
          >
          > 500 Can't connect to pc-rizzuto-p:9999 (Timeout)
          Agree. Fixed list:

          OK Transport + OK SOAP
          1. 200 OK + SOAP message (normal result)

          Error Transport + no SOAP
          2a. 500 Server Error + error message (not SOAP)
          2b. 400 Bad Method + error message (not SOAP)
          2c. 510 Not Extended + error message (not SOAP)
          2d. All other errors

          Error Transport + Fault SOAP
          3a. 500 Server Error + SOAP message (Fault result)
          3b. 400 Bad Method + SOAP message (Fault result)

          OK transport + Fault SOAP
          4. 200 OK + SOAP message (Fault result)

          > In that case, what should I get as the second parameter to the
          > fault
          > handler? In the debugger, @_ has length 2, and print $_[1], but
          > print ref
          > $_[1] returns an empty string. Is that because the content of the
          > response is empty?
          Exactly. ref $_[1] will return empty string even if $_[1] is not
          empty, but doesn't represent any referense and contains plain string,
          like 'abc'. That means that content of message either empty or not
          parsed.

          Best wishes, Paul.


          __________________________________________________
          Do You Yahoo!?
          Get personalized email addresses from Yahoo! Mail - only $35
          a year! http://personal.mail.yahoo.com/
        • Ray Rizzuto
          Paul, I had a minor typo. In a timeout situation, in the fault handler: print $_[1] prints an empty string print defined $_[1] prints 1 print ref $_[1]
          Message 4 of 9 , Feb 14, 2001
          • 0 Attachment
            Paul,
             
            I had a minor typo.  In a timeout situation, in the fault handler:
             
            print $_[1] prints an empty string
            print defined $_[1]  prints 1
            print ref $_[1]  prints an empty string
             
            Since this is a transport error $_[1] is string, which is why ref $_[1] is empty.  Since the content of the returned message is empty in the case of a timeout, that explains why $_[1] is also an empty string.
             
            Ray
            -----Original Message-----
            From: Paul Kulchenko [mailto:paulclinger@...]
            Sent: Wednesday, February 14, 2001 4:16 PM
            To: soaplite@yahoogroups.com
            Subject: RE: [soaplite] Re: on_fault

            Hi, Ray!

            --- Ray Rizzuto <ray.rizzuto@...> wrote:
            > In your list of errors, I don't see the case I'm experiencing,
            > which is a timeout:
            >
            > 500 Can't connect to pc-rizzuto-p:9999 (Timeout)
            Agree. Fixed list:

            OK Transport + OK SOAP
            1. 200 OK + SOAP message (normal result)

            Error Transport + no SOAP
            2a. 500 Server Error + error message (not SOAP)
            2b. 400 Bad Method + error message (not SOAP)
            2c. 510 Not Extended + error message (not SOAP)
            2d. All other errors

            Error Transport + Fault SOAP
            3a. 500 Server Error + SOAP message (Fault result)
            3b. 400 Bad Method + SOAP message (Fault result)

            OK transport + Fault SOAP
            4. 200 OK + SOAP message (Fault result)

            > In that case, what should I get as the second parameter to the
            > fault
            > handler?  In the debugger, @_ has length 2, and print $_[1], but
            > print ref
            > $_[1] returns an empty string.  Is that because the content of the
            > response is empty?
            Exactly. ref $_[1] will return empty string even if $_[1] is not
            empty, but doesn't represent any referense and contains plain string,
            like 'abc'. That means that content of message either empty or not
            parsed.

            Best wishes, Paul.


            __________________________________________________
            Do You Yahoo!?
            Get personalized email addresses from Yahoo! Mail - only $35
            a year!  http://personal.mail.yahoo.com/


            To unsubscribe from this group, send an email to:
            soaplite-unsubscribe@yahoogroups.com


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