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

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

Expand Messages
  • 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 1 of 5 , Aug 31, 2006
      --- 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 2 of 5 , Aug 31, 2006
        --- 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 3 of 5 , Aug 31, 2006
          --- 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.