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

try/catch blocks within Connection util make debugging sort of difficult

Expand Messages
  • Derek
    I don t have ready access to an early version of Y!UI to DIFF, but are the try/catch blocks within the 0.11.3 Connection util new? If so, that would certainly
    Message 1 of 5 , Aug 31, 2006
    • 0 Attachment
      I don't have ready access to an early version of Y!UI to DIFF, but are
      the try/catch blocks within the 0.11.3 Connection util new? If so,
      that would certainly explain why my callback functions are no longer
      throwing JS errors.

      Looking at the util code, I can understand the addition.... but is
      there some other way of handling the logic? Maybe through object
      detection or something? Please correct me if I'm wrong, but it makes
      it VERY difficult to debug code when Y!UI is supressing all of the
      error messages!

      Once again, thanks guys, you're still making my life easier :)

      -d
    • Thomas S. Sha
      ... The debug version of connection manager will log the callback JS errors to the logger console. Regards, Thomas
      Message 2 of 5 , Aug 31, 2006
      • 0 Attachment
        --- In ydn-javascript@yahoogroups.com, "Derek" <tkvgzcf02@...> wrote:
        >
        > I don't have ready access to an early version of Y!UI to DIFF, but are
        > the try/catch blocks within the 0.11.3 Connection util new? If so,
        > that would certainly explain why my callback functions are no longer
        > throwing JS errors.
        >
        > Looking at the util code, I can understand the addition.... but is
        > there some other way of handling the logic? Maybe through object
        > detection or something? Please correct me if I'm wrong, but it makes
        > it VERY difficult to debug code when Y!UI is supressing all of the
        > error messages!
        >
        > Once again, thanks guys, you're still making my life easier :)
        >
        > -d
        >

        The debug version of connection manager will log the callback JS
        errors to the logger console.

        Regards,
        Thomas
      • Derek
        ... So it is. Unfortunately I think I ve stumbled upon a bug or some other general weirdness with Connection and Logger. First off, while re-arranging some
        Message 3 of 5 , Aug 31, 2006
        • 0 Attachment
          --- In ydn-javascript@yahoogroups.com, "Thomas S. Sha" <tsha@...> wrote:
          > The debug version of connection manager will log the callback JS
          > errors to the logger console.
          >
          > Regards,
          > Thomas

          So it is. Unfortunately I think I've stumbled upon a bug or some other
          general weirdness with Connection and Logger.

          First off, while re-arranging some object literal methods, I left a
          trailing comma in (which IE6/7 likes to complain about). i.e.:

          ====

          var obj = {
          'a' : function() { },
          'b' : function() { },
          'c' : null,
          }

          ====

          Note the comma after the null. With Logger running and the debug
          version of Connection, no error was reported at all. With Logger
          running and the normal version of Connection running, IE reports the
          error as it should. Not sure what is up with that, but it seems to
          have something to do with Window-level errors. I used the debugger;
          command with IE and stepped through the code. It worked its way to
          Logger and it identified it as a Window error. Then it jumped in to
          several internal IE files ('ieframe/ieerror.dlg' for example) and
          thats when I aborted the trace.

          After I fixed that, I went back to testing. In one particular
          callback, without using the debug version of Connection, the code
          worked great. When I used the debug version of Connection however, the
          code stopped without reporting any error in IE6/7. Using the debugger;
          command with IE, I was able to isolate the problem.

          ====

          var listContainerEl = YAHOO.util.Dom.get('list_container'); // at this
          point of execution, an empty DIV. it is populated with other DIVs at a
          later stage and this block is called again

          YAHOO.util.Dom.batch(
          YAHOO.util.Dom.getElementsByClassName('display-block', 'div',
          listContainerEl),
          function(el) {
          YAHOO.util.Dom.removeClass(el, 'display-block');
          }
          );

          ====

          Again, with Logger running and the debug version of Connection
          running, the method that batch is to use is executed once and then the
          code execution just stops without any error reported anywhere.

          I have not had the chance to put this in an isloated test case yet to
          see the exact cause of this issue. I would like to say that I think
          using the try/catch blocks really does make it that much harder to
          debug code, even with using the Logger. With Logger catching
          everything, IE won't auto-launch the debug util and jump to the line
          number. Firefox with Firebug won't let you jump to the debugger tool.
          And if there is a problem with the Logger util, its very laborious to
          track down weird issues like this with absolutely no indication as to
          the type of error and where it is occurring. You basically have to
          resort to alert debugging which is always fun :)

          I think Logger is great to use as a console for IE and the like, and
          its good for the occassional random error. But I wouldn't depend on
          upon it for full-fledge bug hunting just yet.

          If the try/catch blocks stay in, I guess I'll just have to overwrite
          the method without them and just deal with the future upgrade
          headaches. They are much easier to deal with than hunting down random
          bugs.

          If you have any more questions, please ask. I'd love to see this issue
          resolved. Once again, thanks for a great library.

          -d
        • Derek
          ... With some more testing, I discovered that even though the code is stopping in that block of code, the entire issue was actually caused by an invalid method
          Message 4 of 5 , Aug 31, 2006
          • 0 Attachment
            --- In ydn-javascript@yahoogroups.com, "Derek" <tkvgzcf02@...> wrote:
            > ====
            >
            > var listContainerEl = YAHOO.util.Dom.get('list_container'); // at this
            > point of execution, an empty DIV. it is populated with other DIVs at a
            > later stage and this block is called again
            >
            > YAHOO.util.Dom.batch(
            > YAHOO.util.Dom.getElementsByClassName('display-block', 'div',
            > listContainerEl),
            > function(el) {
            > YAHOO.util.Dom.removeClass(el, 'display-block');
            > }
            > );
            >

            With some more testing, I discovered that even though the code is
            stopping in that block of code, the entire issue was actually caused
            by an invalid method call. I was calling this.method() instead of
            self.method() within a callback that is executed when a user clicks on
            an object with the above mentioned listContainerEl. I believe I've
            noticed this elsewhere with errors not getting reported. Whenever you
            encounter a 'X has no properties' error, it is not getting picked up
            by the Logger at all.

            What I don't get is why the code is stopping at the point that it
            does. Maybe it has to do with the placement of the try/catches?

            -d
          • Thomas S. Sha
            ... ... I understand your concern. In retrospect the try/catch blocks, specifically in handleTransactionResponse(), could be removed in the debug
            Message 5 of 5 , Aug 31, 2006
            • 0 Attachment
              --- In ydn-javascript@yahoogroups.com, "Derek" <tkvgzcf02@...> wrote:
              <snip>
              > see the exact cause of this issue. I would like to say that I think
              > using the try/catch blocks really does make it that much harder to
              > debug code, even with using the Logger. With Logger catching
              > everything, IE won't auto-launch the debug util and jump to the line
              > number. Firefox with Firebug won't let you jump to the debugger tool.
              > And if there is a problem with the Logger util, its very laborious to
              > track down weird issues like this with absolutely no indication as to
              > the type of error and where it is occurring. You basically have to
              > resort to alert debugging which is always fun :)
              >
              > I think Logger is great to use as a console for IE and the like, and
              > its good for the occassional random error. But I wouldn't depend on
              > upon it for full-fledge bug hunting just yet.
              >
              > If the try/catch blocks stay in, I guess I'll just have to overwrite
              > the method without them and just deal with the future upgrade
              > headaches. They are much easier to deal with than hunting down random
              > bugs.

              I understand your concern. In retrospect the try/catch blocks,
              specifically in handleTransactionResponse(), could be removed in the
              debug version so errors/exceptions thrown in the callback aren't
              "caught". In the meantime, please feel free to remove it[the
              try/catch blocks] for testing and debugging.

              The try/catch was necessary to prevent FF from throwing infinite
              errors when JS errors are encountered in the callback; it appears the
              transaction becomes reentrant. Insofar as I have tested, IE, Opera,
              Safari have not exhibit this behavior. Hopefully, I will have a more
              discrete solution to supersede the current logic at some point.

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