C++ exceptions

[eko...@gmail.com]

Are there any plans for "special" handling of C++ exceptions:

#include <cstdio>

void abc()
{
throw 1;
}

int main()
{
try {
abc(); // A
printf("bub\n");
} catch(...) {
printf("dasd\n"); // B
}
}

If I step over line A, the program will simply exit instead of going
to line B. GDB will do the same thing. MS Visual studio debugger would
stop on line B, however. This is the *only* reason I still haven't
fully switched to Linux for development.

[C. Vlasceanu]

Right now you can make the debugger stop at the throw site (from the menu bar, select Edit -> Options -> Language -> Break on Exceptions).

If I understand correctly, you would like to be able to stop at the catch site as well.
Shouldn't be too difficult a feature to add, I will look into it.

Thanks for your interest in Zero!
   Cristian

--
the-free-meme.blogspot.com

[eko...@gmail.com]

Yes, the same approach is also in the GDB manual. Stopping at all
throw sites can be problematic, though.

Imagine you have a network application, where each layer is
implemented in its own group of functions (let's just assume A-D
layers are implemented in our web browser):

A. app. layer (web browser)
B. app. layer (HTTP client library)
C. basic reliability layer (like TCP)
D. unreliable transport (like IP)
E. ethernet, ...

Lets assume that I'm stepping through code in layer B and I'm
interested why it fails to parse certain server responses - errors are
signalled using exceptions. I have two options:
- break on exceptions off: I'm stepping over functions in B and *bam*,
suddenly the debugger loses control because of exception, all I get is
web browser (layer A) displaying "Server sent broken response"
- break on exceptions on: Now I am getting a storm of exceptions from
D (failed sends), because I am on a faulty network. However layer C
handles basic transmission errors so most exceptions do not get to B,
but I'm still seeing 5 exceptions per second that I'm not interested
in!

VS debugger solves this by stopping only when *current* stack frame
would unwind (I hope these are the correct terms, I don't have any
experience in writing debuggers). Unfortunately, VS stops on the first
line of exception handler, which is a bit late. So the best way would
be to stop when exception is thrown. Code example:

#include <cstdio>

void xyz()
{
throw 1; // D
}

void abc()
{
try {
xyz();
} catch(...) {}
throw 1; // C

}

int main()
{
try {
abc(); // A
printf("bub\n");
} catch(...) {
printf("dasd\n"); // B
}
}

When you step over the line A:
- GDB, zero: stop on D or nowhere
- VS: stops on B
- ideal debugger: stops on C

[eko...@gmail.com]

And thanks for writing Zero! It's really refreshing to see something
new happening in the linux debugger land.

On Mar 2, 12:37 am, "C. Vlasceanu" <cristi.vlasce...@gmail.com> wrote:

[cristiv]

I have implemented the "stop at B" behavior, which works when "Break
At Exceptions" is NOT set (otherwise the debugger stops on each
throw). This is an improvement IMO over the initial behavior, thanks
for suggesting it. If you want to try it out, the Gutsy and Fedora 8
builds available on the download page sport the feature.

I agree that ideally the debugger should break on line C as per your
example; however this is very difficult too implement given the debug
information that is currently generated by the compiler. I will give
it some more thought, for now I believe breaking at the catch block is
a good compromise.

Regards,
Cristian

[eko...@gmail.com]

Wow, that was fast! I've just checked it and it really does work.