Re: 3.15 C++ Exception classes

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

On Feb 21, 2006, at 18:54 , Andrew Johnson wrote:
> problems with using the std::exception::what() are how/when to do  
> the conversion to char*, and in a low memory situation the act of  
> allocating the storage for the string itself may fail resulting in  
> a bad_alloc exception instead of the one we wanted to throw.  Jeff  
> would also mention the issue of giving out pointers to internal  
> storage...
Well, that API is not 100% fool-proof, but usable.
It's a const char * into something that belongs to the exception,
so you can't mess up someone else's buffer.
Yes, if you keep the char * past the lifetime of the exception,
it'll point to an invalid memory location,
so you're free to shoot yourself in the foot.

> How do you decide how big a string buffer to allocate, and what if  
> you run out of memory in the exception class' constructor?
The out-of-memory argument might be artificial.
I see these realistic cases:
1) A memory allocation fails because by accident you've tried to  
allocate 5GB.
   In that case you do have 1k left to allocate a nice looking string.
2) You're fully out of mem, not even 100 bytes left for the error  
message
   -> you're really stuck and I doubt any special string reader  
stuff will help you out,
      because you won't be able to print it, can't open a dialog box,
      can't send it to a message logger, ...
   You'll notice that you're out of mem, you don't need the  
exception to tell you anyway.

In any case, the std::exception.what() is what's given,
it's what you have to catch in order to capture
runtime library exceptions,
so we either live with it or quit using C++.

> Does the file & line information actually have to be included in  
> the thrown object?
>   I notice that in 3.15 Jeff is using a macro called  
> 'epicsThrowTrace' for all throws inside his code; the macro calls a  
> function before throwing the actual exception object:
>
> #define epicsThrowTrace epicsThrowLocTrace(__FILE__, __LINE__); throw
Sure, that's nice.
In other cases you might want to throw not the __FILE__ & __LINE__ of  
C++ code
but the filename of the database file that's being parsed and the
line in there that has the syntax error.
Having an exception that includes the option of passing some name &  
line number
allows both.

> The epicsThrowLocTrace() function conditionally calls errlogPrintf 
> () to log the throw's file & line number based on a global  
> setting.  This design doesn't burden the compiler with copying the  
> file and line number into the exception object; lets face it, that  
> data is of absolutely no use to the catch() handler, so why throw  
> it in the first place?
Use whatever you want to log the errors, as long as an exception  
looks like std::exception,
and I think we're reaching agreement there:
> > ..the primary interface .. is the what() that comes
> > with the std::exception.
> I'm starting to think you're right there, but I like the idea of  
> being able to postpone the string conversion so it can go straight  
> into the catcher's buffer.
Yes, you can defer the string creation.
I don't think it buys much.
If you threw exceptions with each processed records,
that would certainly cut into your recs-per-second rate.

But the process of throwing and unrolling the stack is
already involved.
Since nobody mentioned "Effective C++", yet, I'll do it:
More Effective C++, Understand the costs of exception handling:
"Compared to a normal function return, ... throwing an exception
might be as much as _three_orders_of_magnitude_ slower".

That's why exceptions are for errors that make
you step back and reconsider,
so simply creating the string in the constructor
hardly matters.

-Kay