Re: Exceptions

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

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:

Number of packages (.ads files)                   :     196
Number of package bodies (.adb files)             :     147
Total source lines (including blanks and comments): 201_731
Total number of lines with semicolons             :  42_935
Total number of subprograms                       :   6_292

Exceptions declared                               :      87

Explicit raise statements (with exception name)   :     239
- of Constraint_Error (note 1)                    :      20
- of Program_Error    (note 1)                    :      12
- of application-defined exceptions               :     207

Exception-handler sequences (note 2)              :     219
Exception handlers (note 3)                       :     275

Handlers that "eat "exceptions (note 4)           :     180
- eat specific application-defined exception(s)   :     129
- eat specific language-defined exception(s)      :      34
- eat "others"                                    :      17

Handlers that raise or re-raise exceptions        :     102
- propagate same application-defined exception    :      13
- propagate same language-defined exception       :      22
- propagate same "others" exception               :      28
- change app-def. exc. to other app-def. exc.     :      20
- change language-def. exc. to app-def. exc.      :      18
- change app-def. exc. to language-def. exc.      :       1


Notes:
   1. Of the language-defined exceptions, only
      Constraint_Error and Program_Error are raised
      explicitly (by "raise <name>").
   2. An "exception-handler sequence" is the list of
      exception_handlers at the end of a handled_-
      sequence_of_statements.
   3. Whether for one exception, several exceptions,
      or "others".
   4. Handlers that do not contain "raise" statements.

Some of the above was counted by hand from "grep" outputs, so the 
numbers may be off by a couple of units.

It is noteworthy that most exception-handler sequences (total: 219) 
only have one exception handler (total: 275), although this single 
handler often handles several exceptions, or "others".

> 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. 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.

> 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.

> 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). Good error tolerance may require more local handlers to 
clean up local state, before (possibly) passing the exception to 
higher levels.

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .