EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: 3.15 C++ Exception classes
From: Kay-Uwe Kasemir <[email protected]>
To: Core talk list <[email protected]>
Date: Wed, 22 Feb 2006 09:32:42 -0500

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


Replies:
Re: 3.15 C++ Exception classes Andrew Johnson
References:
3.15 C++ Exception classes Andrew Johnson
Re: 3.15 C++ Exception classes Kay-Uwe Kasemir
Re: 3.15 C++ Exception classes Andrew Johnson

Navigate by Date:
Prev: Fwd: Re: 3.15 C++ Exception classes Benjamin Franksen
Next: Re: 3.15 C++ Exception classes Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: 3.15 C++ Exception classes Andrew Johnson
Next: Re: 3.15 C++ Exception classes Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024