Re: Exceptions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 10 Dec 2007 14:09:31 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
> 
>  > [some questions, see below]
> 
> I'm not sure if Dmitry really wants answers to his questions below 
> -- perhaps they were merely rhetorical -- but they tickled my 
> curiosity, so here is one data point from my main Ada application:

Thank you for the figures. It is really interesting.

>> 1. How often do you declare a new exception when writing a new subprogram?
>> My guess is about 1 / 10_000.
> 
>  From the numbers above: 87 / 6_292 = 138 / 10_000.

One per hundred also. As for me I tend to reuse IO_Exceptions if semantics
is close, so my figure should be much lesser.

> In some cases 
> one declared exception can be raised in several subprograms, but I 
> think the average number of subprograms that can raise a given 
> application-defined exception is between 1 and 2, not larger, in 
> this application.

This is a very low figure. But as I said, I reuse exceptions much. A
possible danger is to overload an exception too much (like Constraint_Error
already is).

This is IMO a question of custom and also of the language design. When
exceptions tend to propagate out of the application, one would certainly
like to make them "meaningful" indicating the fault reason as precise as
possible. This is not what I wanted from Ada. I'd like to have all
exceptions handled. So I treat them rather as signals within and for the
application. I don't buy exceptions as a debugging tool.

>> 2. How often does a caller "eat" an exception of the callee instead of
>> propagating it further? My guess is 1 / 10.
> 
> My numbers do not separate between exceptions propagated from calls 
> and exceptions raised within the handled sequence-of-statements 
> itself. But my feeling is that at least half of the handlers are 
> meant to catch exception from calls, and I don't think that there 
> is any systematic difference in the proportion of "eaters" versus 
> "propagators" between the two cases.
> 
> So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = 
>   6.5 / 10.

Interesting. I didn't measured my code, but I expect more scopes where
exceptions propagate unhandled. That depends on how much refactoring is
done. Actually, I have an impression that many exception-related bugs
appear while code refactoring and other small apparently equivalent code
modifications, which in turn are not almost equivalent.

>> There is not that many handlers in a good designed code.
> 
> That is too generalized. I think that the number of handlers is 
> partly a matter of personal style (preference for error-code 
> parameters vs exceptions) and partly depends on the required level 
> of error tolerance (ability to continue processing in spite of 
> errors).

Yes

> Good error tolerance may require more local handlers to 
> clean up local state, before (possibly) passing the exception to 
> higher levels.

Possibly, however there is a concurring mechanism for clean-ups, I mean
controlled types. In many cases Finalize does what otherwise a handler
would.

> The application behind the numbers given above is not required to 
> be error-tolerant. Thus, many exceptions can simply be propagated 
> to a high level, without passing through many local clean-up 
> handlers on the way.

Yes, but again it is probably not about being error-[in]tolerant. I think
the overall code structure plays a role here. When I refactor small
subprogram doing this or that thing, I often leave exception handling
functionality to another piece of code. Maybe this is my personal
motivation behind longing for contracted exceptions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de