Re: Exceptions

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1kxk3hlfa25dw$.fl2wvbn0tpbg$.dlg@40tude.net...
...
> 1. How often do you declare a new exception when writing a new subprogram?
> My guess is about 1 / 10_000.

For me, it is more like 1/100. Most subsystems get their own set of
exceptions.

> 2. How often does a caller "eat" an exception of the callee instead of
> propagating it further? My guess is 1 / 10.

This I agree with, and it is my primary objection to exception contracts.
This means that you'll have to write long-winded handlers and/or contracts
on 9/10 of the calls. That is, it is the common case that takes more work.
That's usually bad.

> There is not that many handlers in a good designed code. This is probably
> the reason why people forget to handle exceptions properly. They are not
> that visible.

That's true: a lot of systems that I write have no handlers at all because
any exception being raised is a bug, and I want to know. The biggest problem
is insuring enough test coverage to make sure that the (latent) exceptions
(that is, bugs) get raised.

Most of the handlers I do write are of the form:
    begin
          Open (...); -- File or socket or ...
    exception
          when others => -- Couldn't open whatever. Abort program or
process.
    end;
    -- Use the open file.

But I'm not usually writing safety-critical systems. For programs that need
to keep running (for example, a  mail server), I use a single global others
handler that logs any exceptions, since there should be none. But there
would no way to prove that statically, and I don't think I'd want to have to
write code structured to be able to try.

                                Randy.