Mike Hearn <[EMAIL PROTECTED]> writes:
> This isn't reliable though, what about apps that swallow all exceptions
> with a try/except block? Ideally you want this sort of thing to just
> work and not have to figure out why your backtrace is never happening.
In that case you have to start the debug
On Thu, 2004-08-19 at 17:02 -0700, Alexandre Julliard wrote:
> A custom exception yes; there's no need for a vectored handler, the
> whole point is to use the normal mechanism so that the exception gets
> to the debugger.
This isn't reliable though, what about apps that swallow all exceptions
with
Mike Hearn <[EMAIL PROTECTED]> writes:
> So for this functionality you want a custom exception with a vectored
> handler?
A custom exception yes; there's no need for a vectored handler, the
whole point is to use the normal mechanism so that the exception gets
to the debugger.
--
Alexandre Julli
On Wed, 18 Aug 2004 13:13:13 -0700, Alexandre Julliard wrote:
> No, the backtrace should be done by the debugger.
So for this functionality you want a custom exception with a vectored
handler?
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,
fai
Robert Shearman <[EMAIL PROTECTED]> writes:
> Alexandre Julliard wrote:
>
>>Well, I can also imagine a lot of cases where the in-process backtrace
>>won't work right, the main one being that since the code will never be
>>used unless you want a backtrace, when you try to use it you'll
>>realize th
Alexandre Julliard wrote:
Andreas Mohr <[EMAIL PROTECTED]> writes:
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 d
Andreas Mohr <[EMAIL PROTECTED]> writes:
> 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 pas
Andreas Mohr wrote:
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. :-)
Yes, without his work this patch would have been impossible. A lot
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 d
Me too! *jumps up and down* In Java you can say this:
new Exception().printBackTrace();
or some equivalent to get a printout of where you are, and it's very
convenient.
I can see the reasoning behind keeping the code in the debugger then
triggering it using a custom exception though, as that way
Hi,
On Wed, Aug 18, 2004 at 12:22:50AM -0400, Dimitrie O. Paun wrote:
> On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote:
> > Robert Shearman <[EMAIL PROTECTED]> writes:
> >
> > I think it's better to let the debugger take care of that. If you
> > don't want a real breakpoint yo
On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote:
> Robert Shearman <[EMAIL PROTECTED]> writes:
>
> I think it's better to let the debugger take care of that. If you
> don't want a real breakpoint you could define a custom exception to
> tell winedbg to just dump the backtrace an
Robert Shearman <[EMAIL PROTECTED]> writes:
> I propose the addition of this new debug tool that will allow
> developers to output backtraces to the console, without having to
> interact with a debugger. It can give a useful indication of how
> functions are being called in situations where a brea
14 matches
Mail list logo
