... ... I understand your concern. In retrospect the try/catch blocks, specifically in handleTransactionResponse(), could be removed in the debug
Message 1 of 5
, Aug 31, 2006
> 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
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.
Your message has been successfully submitted and would be delivered to recipients shortly.