Re: Exceptions

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
.

Relevant Pages

  • Re: Comparison with False - something I dont understand
    ... built-in exceptions which are thrown by library functions to follow its ... to place the error handling code wherever it makes sense to do so. ... and in the bounderies between subsystems. ... it up to the error handlers on top of the boundry. ...
    (comp.lang.python)
  • Re: Exceptions
    ... programming with functions that return objects with run-time ... easily use error codes and must use exceptions to signal problems. ... handlers spoiling each and other program block. ... middle layer that reuses those primitives, ...
    (comp.lang.ada)
  • Re: Exceptions
    ... Such functions cannot easily use error codes and must use exceptions to signal problems. ... handlers at all and thus propagate all exceptions raised in them or in their callees. ... I think all subprograms would need contracts, not just the few subprograms that have exception handlers. ... The contract has to be in the subprogram declaration, while the presence or absence of exception handlers is a property of the body. ...
    (comp.lang.ada)
  • Re: Exceptions
    ... propagating it further? ... So you do not need to place any handlers in 9/10 subprograms. ... 'How does a language feature affect programs?' ... contracted exceptions will sufficiently improve quality of Ada programs. ...
    (comp.lang.ada)
  • Re: Best way to handle exceptions with try/finally
    ... statements at the end of functions to make an attempt at being clean. ... realize that a lot of the time functions will just return but I was ... of finally if you want exceptions to propagate. ...
    (comp.lang.python)