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

debugging servers appears to be blind

Expand Messages
  • fulkohew <fulkohew@yahoo.com>
    When I m writting perl based SOAP servers and there is a typo I don t get any error messages from the compiler, either at compile time or run time. All I know
    Message 1 of 4 , Feb 11 7:02 AM
    • 0 Attachment
      When I'm writting perl based SOAP servers and there is a typo I don't
      get any error messages from the compiler, either at compile time or
      run time. All I know (can see) is that I don't get the output I expect.

      This makes debugging very tedious.

      Its maybe because I'm using auto-dispatching, but I'm flying blind
      and don't know where to start to try to get syntax error messages
      back. I don't even know what test code to post to show an example of
      my issue.

      Any help would be appreciated.
      TIA
      Fulko
    • Keanan Smith
      All of the warnings/errors from every source go *somewhere*, where depends on in what context you call them. For instance, In SOAP Server: Any Die Statements
      Message 2 of 4 , Feb 11 9:10 AM
      • 0 Attachment
        All of the warnings/errors from every source go *somewhere*, where depends
        on in what context you call them.

        For instance,

        In SOAP Server:

        Any 'Die' Statements which happen *in dispatched code* get caught (Via eval
        and $@) and passed back to the client as a faultstring,

        Any Compile time error statements happen normally (Ie. get sent to the
        console of the server, or STDERR, more accurately, (I personally redirect
        this to a log, it's nice for debugging that way.))

        Any 'warnings' also go to STDERR, as normal (see above :)

        Any system-type errors go into the appropriate system error variable, as
        per-normal (For instance $! and $^E for OS specific stuff)

        On the *client* side, everything should happen normally.

        So I have to assume if you aren't seeing your error messages, 1 of 3 things
        is true:

        1. You're executing code in an eval yourself, and not checking $@,

        2. You're 'dying' out of executed (dispatched) code server-side, but the
        client isn't checking the faultstring.

        3. You're experiencing server-side compile-time errors (or warnings), but
        don't have a console for the errors to appear in.

        possibly some combination of the 3 :)



        -----Original Message-----
        From: fulkohew <fulkohew@...> [mailto:fulkohew@...]
        Sent: Tuesday, February 11, 2003 8:03 AM
        To: soaplite@yahoogroups.com
        Subject: [soaplite] debugging servers appears to be blind



        When I'm writting perl based SOAP servers and there is a typo I don't
        get any error messages from the compiler, either at compile time or
        run time. All I know (can see) is that I don't get the output I expect.

        This makes debugging very tedious.

        Its maybe because I'm using auto-dispatching, but I'm flying blind
        and don't know where to start to try to get syntax error messages
        back. I don't even know what test code to post to show an example of
        my issue.

        Any help would be appreciated.
        TIA
        Fulko




        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/
      • quinn@fetter.org
        ... Thanks to Keanan for his detailed explanation of error streams. fulkohew, another solution to catch compile-time errors is to run perl -c YourModule.pm
        Message 3 of 4 , Feb 11 10:43 AM
        • 0 Attachment
          On Tue, Feb 11, 2003 at 03:02:58PM -0000, fulkohew <fulkohew@...> wrote:
          >
          > When I'm writting perl based SOAP servers and there is a typo I don't
          > get any error messages from the compiler, either at compile time or
          > run time. All I know (can see) is that I don't get the output I expect.

          Thanks to Keanan for his detailed explanation of error streams.

          fulkohew, another solution to catch compile-time errors is to run
          'perl -c YourModule.pm' on the command line before trying to access
          the service via SOAP. Note that you must call 'perl -c' on one
          module at a time; if you pass multiple module names, it will
          silently fail to check all but the first!

          perl -c will catch syntax errors. However, if you accidentally mistype
          method or subroutine names, the error won't show up till run time,
          because that's when Perl does method dispatch.

          I hope this helps. :)
          --Q
        • fulkohew <fulkohew@yahoo.com>
          ... I will investigate this further. My client does have a handler which I presumed would emit something if it were being called. From the sample code, I
          Message 4 of 4 , Feb 11 12:59 PM
          • 0 Attachment
            Keanan Smith <KSmith@n...> and quinn@... replied:

            > Any 'Die' Statements which happen *in dispatched code* get caught
            > Via eval and $@) and passed back to the client as a faultstring,

            I will investigate this further. My client does have a handler
            which I presumed would emit something if it were being called.
            From the sample code, I have:

            on_fault => sub {
            my($soap, $res) = @_;
            die ref $res ? $res->faultdetail : $soap->transport->status, "\n";
            };

            But this apparently catches SOAP issues, not server side application
            issues.

            > Any Compile time error statements happen normally (Ie. get sent
            > to the console of the server, or STDERR, more accurately, (I
            > personally redirect this to a log, it's nice for debugging
            > that way.))
            >
            > Any 'warnings' also go to STDERR, as normal (see above :)

            As I would have expected to see too.

            > Any system-type errors go into the appropriate system error
            > variable,as per-normal (For instance $! and $^E for OS specific
            > stuff)

            Hmmm.

            > On the *client* side, everything should happen normally.

            Well, because there is a server side error, the client can't
            invoke the remote method. ie. it doesn't exist. And in Perl
            tradition, missing functions are silently ignored, so the client
            side is always quiet.

            > So I have to assume if you aren't seeing your error messages,
            > 1 of 3 things is true:
            >
            > 1. You're executing code in an eval yourself, and not checking $@,

            Nope, not knowingly.

            > 2. You're 'dying' out of executed (dispatched) code server-side,
            > but the client isn't checking the faultstring.

            I'll check that. (see code snippet above.)

            > 3. You're experiencing server-side compile-time errors (or
            > warnings), but don't have a console for the errors to appear in.

            If it wern't for the fact that I do have a console, thats what I
            would say was happening.

            > another solution to catch compile-time errors is to run
            > 'perl -c YourModule.pm' on the command line before trying
            > to access the service via SOAP.

            This will catch my bugs! Thanks. I'll make a makefile that runs
            perl -c first, on all of my modules and barfs if neccessary first
            before running the server.
          Your message has been successfully submitted and would be delivered to recipients shortly.