Hi,
On Wed, Aug 18, 2004 at 09:27:53AM +0100, Mike Hearn wrote:
My problem with this approach is that it relies on the exception actually getting through to the debugger instead of being trapped by the program code and swallowed. I guess we could install a vectored handler to boot the debugger and such but now the code is a lot more complex and confusing for newbies than just having some inline functions in the headers. As if the SEH code wasn't already confusing enough!
Indeed. I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ...
That's why a "no frills" debugging mechanism is a good idea IMHO.
Andreas Mohr
P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)