Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 22 Feb 2006 10:46:39 +0100

Sorry, this should have been going to core-talk in the first place.

----------  Forwarded Message  ----------

Subject: Re: 3.15 C++ Exception classes
Date: Tuesday 21 February 2006 12:01
From: Benjamin Franksen <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Jeff Hill <[email protected]>

On Tuesday 21 February 2006 00:21, Andrew Johnson wrote:
> severity(): I don't like this; the severity information should be
> implicit in the hierarchy of the class that is being thrown.  I
> expect to be able to write a try/catch phrase that could catch
> warnings but not errors or fatalities; I don't want to catch
> everything and then have to re-throw anything that's more severe than
> a warning.  I'm also not convinced that the thrower can determine the
> severity of an exception in practice.  Therefore I'm not going to
> include the severity part.

Hi Andrew & Jeff,

I am not convinced, neither by the argument above ("write a try/catch
phrase that could catch warnings but not errors or fatalities") nor by
the Jeff's design where the severity is a class member.

IMHO, exceptions should not be classified at all into severity types.

Instead, I would propose to create /one/ special exception type that is
reserved for 'assert' style failures, i.e. failures that can only
becaused by broken or corrupted code. IIRC, this is what a 'fatal'
severity normally means in Jeff's code.

All other exceptions are normal (i.e. expected) failure conditions.

Warnings, OTOH, can be automatically logged or whatever, but should
NEVER cause an exception to be thrown. For exceptions to be useful in
any way it is of utmost importance to strictly separate between success
and failure. If the requested operation can be (and is) performed in
any way, an exception must /not/ be thrown.

Why?

A typical operation consists of more than one step, where subsequent
steps depend on the results of preceding ones. If executing step N
results in a 'warning' condition, the code cannot just throw an
exception because this would mean that step N+1 is never performed,
which would in turn mean that the whole operation fails (but with a
'real' error this time, not a warning). Thus, to ensure that the whole
operation can still be performed even in case one of the sub-operations
throws (only) a warning-type exception, each sub-operation must be
executed in it's own try/catch block.

However, if we do this, we gain /absolutely nothing/ compared to the
current (C) method of indicating sucess/failure via return values! To
the contrary, the code will become even more verbose and complicated.

Cheers,
Ben

-------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System