On Feb 23, 10:31 am, John J Barton <[email protected]> wrote: > On Feb 22, 9:03 pm, laxeraend <[email protected]> wrote: > > > On Feb 22, 8:26 pm, John J Barton <[email protected]> wrote: > > > > When you see the error message in the console, click on the link on > > > the far right side. > > > It takes you to the source line of the throw. Right click and enter a > > > JS expression to restrict the breakpoint. > > > This will work for basic stuff, like something is null, but there are > > exceptions whose generation can not be tested for with an expression, > > or you don't know what to test for and are trying to break to figure > > it out (e.g exceptions from the JS engine itself or DOM. So it would > > still be useful be able to break on a throw (with filters on the > > exception and location) > > It would be helpful if you gave a concrete example so we can > understand.
When an exception is thrown from opaque (non js) code that you can't examine and see the precise conditions that caused the throw, you want to break first, then investigate interactively, that's what a debugger is for. Your are suggesting that one should investigate first, come up with an expression that perfectly predicts the exception, and only then break. By the time you do that, you don't need to break any more, you've already solved the problem. -- You received this message because you are subscribed to the Google Groups "Firebug" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/firebug?hl=en.
