Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » C / C++ IDE (CDT) » Catching C++ exceptions at point of throw
Catching C++ exceptions at point of throw [message #117573] Thu, 26 August 2004 17:42 Go to next message
Tom Quarendon is currently offline Tom QuarendonFriend
Messages: 23
Registered: July 2009
Junior Member
Is there an option somewhere to make the debugger break when a C++
exception is thrown? Can't find one anywhere...
Re: Catching C++ exceptions at point of throw [message #117975 is a reply to message #117573] Sat, 28 August 2004 17:16 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: adam.n.gordon.saic.com

I haven't seen one, but in my limited understanding of c/c++, if you
don't catch an exception thrown by your program, your program will
terminate anyway - just like in Java.

-Adam

Tom Quarendon wrote:
> Is there an option somewhere to make the debugger break when a C++
> exception is thrown? Can't find one anywhere...
>
>
Re: Catching C++ exceptions at point of throw [message #118227 is a reply to message #117975] Tue, 31 August 2004 09:05 Go to previous messageGo to next message
Tom Quarendon is currently offline Tom QuarendonFriend
Messages: 23
Registered: July 2009
Junior Member
But the point is I that I'm trying to debug a program that is (for
example) terminating unexpectedly because of an exception. In java, I'd
have a nice exception stack trace to go by. In C++ my only hope is to say
to the debugger, "stop when you are about to throw an exception", so I can
examine the stack and the local variables and work out why the exception
is being thrown.

GDB command line allows you to do this via the "catch throw" command.
Visual Studio debugger allows you to set whether you want to stop when
various kinds of signal are encountered, C++ exception, Access Violation,
etc. Would be nice to have the same degree of control in CDT. Indeed the
GDB manual says that if you put a break point on "__raise_exception", you
can even examine the type of exception being raised and thus effectively
put a break point on the throwing of a particular class of exception.

Without this fairly simple ability debugging C++ programs using the CDT
debugger is fairly hard. I would normally use logging rather than a
debugger when debugging C++ programs, but when you get a situation or an
unexpected C++ exception or segv, a debugger is your only friend, so when
it doesn't allow you to do what you need to in those circumstances, you're
in difficulty.

Adam Gordon wrote:

> I haven't seen one, but in my limited understanding of c/c++, if you
> don't catch an exception thrown by your program, your program will
> terminate anyway - just like in Java.

> -Adam

> Tom Quarendon wrote:
> > Is there an option somewhere to make the debugger break when a C++
> > exception is thrown? Can't find one anywhere...
> >
> >
Re: Catching C++ exceptions at point of throw [message #118318 is a reply to message #118227] Tue, 31 August 2004 14:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: alain.nowhere.ca

Tom Quarendon wrote:

> But the point is I that I'm trying to debug a program that is (for
> example) terminating unexpectedly because of an exception. In java, I'd
> have a nice exception stack trace to go by. In C++ my only hope is to say
> to the debugger, "stop when you are about to throw an exception", so I can
> examine the stack and the local variables and work out why the exception
> is being thrown.

C++ ain't Java.
Exceptions are tied to the compiler implemention and the debugger
must know about the implementation. Altough there are efforts to
standardize on this, see gcc web pages concerning C++ ABI.
So we may not be able to support this on all platform.

> GDB command line allows you to do this via the "catch throw" command.
> Visual Studio debugger allows you to set whether you want to stop when
> various kinds of signal are encountered, C++ exception, Access Violation,
> etc. Would be nice to have the same degree of control in CDT. Indeed the
> GDB manual says that if you put a break point on "__raise_exception", you
> can even examine the type of exception being raised and thus effectively
> put a break point on the throwing of a particular class of exception.

It will depend on the compiler you use, for new gcc 3.3.x it should
be __cxa_throw() are something similiar, refere to the recent gdb manual.

But the problem is that gdb still does not give you a way to be
suspended on a __specific__ exception, it just stop at __all__ exceptions.
Not very practicle.

> Without this fairly simple ability debugging C++ programs using the CDT
> debugger is fairly hard. I would normally use logging rather than a
> debugger when debugging C++ programs, but when you get a situation or an
> unexpected C++ exception or segv, a debugger is your only friend, so when
> it doesn't allow you to do what you need to in those circumstances, you're
> in difficulty.

I would correct by saying debugging C++ programs __with exception__ can
be fairly hard.

Meanwhile, you can go at the GDB console in eclipse and type
"catch throw", like you are did with gdb, 'til we find
away to integrate this feature in CDT.

> Adam Gordon wrote:

> > I haven't seen one, but in my limited understanding of c/c++, if you
> > don't catch an exception thrown by your program, your program will
> > terminate anyway - just like in Java.

> > -Adam

> > Tom Quarendon wrote:
> > > Is there an option somewhere to make the debugger break when a C++
> > > exception is thrown? Can't find one anywhere...
> > >
> > >
Re: Catching C++ exceptions at point of throw [message #118877 is a reply to message #118318] Thu, 02 September 2004 10:15 Go to previous messageGo to next message
Tom Quarendon is currently offline Tom QuarendonFriend
Messages: 23
Registered: July 2009
Junior Member
alain wrote:

> C++ ain't Java.

I know. The point I was making was that the ability to stop when an
exception is throws in Java isn't as important as at least you've got a
stack trace to go by.

> Exceptions are tied to the compiler implemention and the debugger
> must know about the implementation. Altough there are efforts to
> standardize on this, see gcc web pages concerning C++ ABI.
> So we may not be able to support this on all platform.


> It will depend on the compiler you use, for new gcc 3.3.x it should
> be __cxa_throw() are something similiar, refere to the recent gdb manual.

You already have different configurations for different kinds of debugger,
executable format etc

> But the problem is that gdb still does not give you a way to be
> suspended on a __specific__ exception, it just stop at __all__ exceptions.
> Not very practicle.

But with a conditional break point based on the parameters passed to the
function it would be possible to break when a specific exception type was
thrown. The ability to break on any exception would be an improvement,
because then at least if you know roughtly where the exception is you can
put a break point in the rough area, then press the button saying "catch
C++ exceptions", and you're home and dry.

> I would correct by saying debugging C++ programs __with exception__ can
> be fairly hard.

Yes that may be so, that's why I'm using a debugger.
But its things like this that means that Eclipse/CDT doesn't stack up too
well against Visual Studio which is tightly integrated with the
debugger/compiler and has all of these facilities. Unfortunately I find
Visual Studio impossible to use because of its bizarre project management
structure and the way it manages compile options across multiple projects,
or doesn't. But that's another rant entirely.
Re: Catching C++ exceptions at point of throw [message #119185 is a reply to message #118877] Thu, 02 September 2004 20:39 Go to previous message
Eclipse UserFriend
Originally posted by: alain.nowhere.ca

Tom Quarendon wrote:

...

> > It will depend on the compiler you use, for new gcc 3.3.x it should
> > be __cxa_throw() are something similiar, refere to the recent gdb manual.

> You already have different configurations for different kinds of debugger,
> executable format etc

No, not really. What I'm trying to tell you: The way exception is done
in C++ is tied to the way the compiler implements it. There is no
std each compiler can do it differently. So the debugger must have
intimate knowledge of the compiler.

> > But the problem is that gdb still does not give you a way to be
> > suspended on a __specific__ exception, it just stop at __all__ exceptions.
> > Not very practicle.

> But with a conditional break point based on the parameters passed to the
> function it would be possible to break when a specific exception type was
> thrown.

See above.

...

> Yes that may be so, that's why I'm using a debugger.
> But its things like this that means that Eclipse/CDT doesn't stack up too
> well against Visual Studio which is tightly integrated with the
> debugger/compiler and has all of these facilities. Unfortunately I find
> Visual Studio impossible to use because of its bizarre project management
> structure and the way it manages compile options across multiple projects,
> or doesn't. But that's another rant entirely.

Visual Studio ships compiler, debugger, headers, libraries all of them
intimitaly tied to the os. To illustrate the point try to use the VS
debugger with something that was compile with gcc ....

But regardeless, your point is well taken and we understand the importance
of exception breakpoint. This email was to make you understand the
technical difficulties of it. CDT works on Linux, Solaris, Windows etc ..
and providing a solution for such a wide range of platforms is not easy.
VS does not have to worry about this.

In essence we are working on it but the solution will probably be tied
to GCC and GDB.
Previous Topic:Storing watch expressions
Next Topic:C++ components and plug-ins
Goto Forum:
  


Current Time: Sun Jun 30 13:28:57 GMT 2024

Powered by FUDForum. Page generated in 0.03121 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top