[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: caught non-std exception

Subject: Re: caught non-std exception
Date: Mon, 20 Mar 2006 12:04:34 -0500
User-agent: Pan/ (As She Crawled Across the Table)

On Sun, 19 Mar 2006 12:31:08 +0100, Ulrich Eckhardt wrote:

> Mike - EMAIL IGNORED wrote:
>> On FC4 with g++ using STL 
> The STL is pretty dead, are you really using it or do you mean the C++
> standardlibrary?

> Also, which version of g++ are you talking about?

g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)

> Some
> people might also not know what FC means (fibre channel?). ;)
They'll survive it.
>> and Posix threads 
> POSIX, its an abbreviation.

Too many caps hurt my eyes.

>> and sockets I am catching an exception  
>> that is not a std::exception.  Any idea what it might be?
> An uncaught exception calls abort() which usually invokes the debugger, so
> it should be possible to find out. Also, if you don't want to catch it
> just don't catch it.

See below

>> An outline of my catch macro is below.
>> #define MY_MACRO \
>>    catch (MyExceptions& e) \
>>    { \
>>        ...  \\ process them \
>>    } \
>>    catch (std::exception& e) \
>>    { \
>>        ...  \\ process them \
>>    } \
>>    catch (...) \
>>    { \
>>        ...  \\ what is this \
>>    }
> - Macros are evil. 

Why? What else would you do here?

> - Don't catch exceptions unless you handle them, as a general advise.

Bad advice.  You may want to catch them at an intermediate
level to provide a more robust product where it is known that 
throws from the lower level can safely be ignored.  It is
useful, however, to log them.

> - You can catch const references. 

> - When catching '...', the only sensible thing to do is to abort/exit or to
> rethrow.

Abort after logging is good.  However, catch(...) should
always be there in case of unexpected circumstances, as was
the case here. See below. By the way, this is the first time
it has caught anything in ten years of use.  The log, which
included the location of the catch, was very helpful in
solving the problem.

> - This looks like a general C++ problem that has nothing to do with g++.

Yes, the problem has already been solved on comp.lang.c++
under the same title.

> cheers
> Uli


reply via email to

[Prev in Thread] Current Thread [Next in Thread]