Re: Exceptions and warnings

[Mike - EMAIL IGNORED]

Andreas Schallenberg wrote:
> 
> Hi NG!
> 
> Background:
> I've a fairly large C++ program which makes
> use of exceptions for error handling.
> Unfortunately the exceptions are thrown nearly
> all the way up to the top of the call stack
> which makes the messages difficult to read.
> In many cases the correct place to append some
> useful information would be at half of that way
> where teh methods known whats going on in a
> broader view.
> 
> Problem:
> I'd like to have some support by gcc on modifying
> these throw/catch behavior. I am looking for a
> way to get a list of method/exception pairs which
> tell me which method does receive an exception but
> does not handle it. This would be quite similar
> to the Java style of doing. But I'd like not to
> break the compile but get a warning.
> 
> My expectation was that this would be quite a
> common problem but found only one NG thread in
> the past which touched this topic (and that wasn't
> gcc specific, too).
> 
> Does anybody know some hints how to get closer
> to this goal?
> 
> RU,
> Andreas
> 
> P.S.:
> I've posted this previously to gnu.gcc.help
> but was pointed to this group since it was
> obviously off-topic there.

1. a. All my classes have: static const char* const className_;
   b. All my methods that can throw have: const char* const methodName;
   c. There are cpp macros that provide src line number and file name.

2. Write your own classes to be thrown and caught, that behave as
   you require.  The info above should be provided in the constuctor,
   along with any other info you need.  A cpp macro could be written
   for use as s constructor argument that easily provides the
information.

   a. The class should have a print method; you could experiment
      with the format.

   b. A base class and an inheritance heirarchy is a good way to go.
      Note that of you catch BaseClass&, you will catch any of them.

3. Write one or more cpp macros to do the catching.  These macros
   should print the exception object, as well as the location
   information about where the exception is caught.  Some of these
   macros could rethrow.

Once these classes are developed, writing code using them is a breeze.
Long experience suggests that this is a good plan.

Mike.