Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 21 Feb 2006 10:36:28 -0600

Hi Ben,

Please reply to core-talk messages on core-talk itself; see

http://www.producingoss.com/html-chunk/setting-tone.html#avoid-private-discussions

for reasons (that book is a good resource for Open Source projects BTW,

with many ideas which I'm trying to introduce to the EPICS community).

Thanks,

- Andrew

Benjamin Franksen wrote:

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

--
There is no S in exprexxo.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System