On Feb 23, 2:43 pm, laxeraend <[email protected]> wrote: > 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.
No, I am suggesting that you give us a specific concrete example so we can understand the situation you experience. I can't improve the debugger for you if I don't know what cases cause you trouble. jjb -- 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.
