Hi Tom, Tom Tromey píše v Pá 22. 02. 2013 v 11:14 -0700:
> Michael> Even better than this would (perhaps) be a "break inside thrower that > Michael> is caught here" type breakpoint - that we could invoke to land us in > Michael> whatever code is going to throw as it does that [ and before it > started > Michael> all the magic cleanup / unwinding work ]. That is - assuming that > it's > Michael> possible for the code to know (at that point) where it will > ultimately > Michael> end up (? ;-) > > I think it isn't possible in general. When an exception is thrown, I > think all that can really be determined is the next catch point. > > What this means is that if you have a series of throws and re-throws, > winding up at some "catch", then the best you could do is stop at the > re-throw that leads to that catch. Even if this is not solving everything / the general case, I think this would still be pretty useful for LibreOffice - I don't remember being bitten by rethrows when debugging LO problems. And always one could set this thing [how to call it, actually? ;-)] where the re-throw happens, and try again - still it would save quite some time compared to first setting a breakpoint to get to the relevant piece of code + catch throw + catch catch + hope that they are the right ones. > Here, suppose the comment marks the catch you are concerned with. > You want to find the throw that leads to this point. > > The original throw in "doit" can only see as far as the catchpoint in > "dd2". That is because arbitrary code can be run there -- for example > it may swallow the exception and no more throwing is even done. > > So this hypothetical breakpoint would only trigger at the re-throw in > dd2. In other words - I'd love if gdb were able to do this even with the re-throw limitation :-) All the best, Kendy _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
