- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Mon, 10 Dec 2007 14:08:50 +0100
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 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
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
Good error tolerance may require more local handlers to
clean up local state, before (possibly) passing the exception to
Possibly, however there is a concurring mechanism for clean-ups, I mean
controlled types. In many cases Finalize does what otherwise a handler
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.
Dmitry A. Kazakov
- Re: Exceptions
- From: Niklas Holsti
- Re: Exceptions
- Prev by Date: Re: Exceptions
- Next by Date: Re: ObjectAda 7.2.2 and VB6 DLLs
- Previous by thread: Re: Exceptions
- Next by thread: Re: Exceptions