Re: Exceptions

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

On Tue, 11 Dec 2007 09:19:37 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
> In my view, a language feature is useful if and only if it
> actually helps reducing the number of bugs.
> 
>>>> 2. How often does a caller "eat" an exception of the callee instead of
>>>> propagating it further? My guess is 1 / 10.
>>> Are you assuming current rules for guessing 10% exception handling,
>>> i.e., no exceptions are announced by the subprogram declaration?
>> 
>> I meant that an exception is typically propagated out of 10 scopes before
>> it gets handled.
> 
> And?

So you do not need to place any handlers in 9/10 subprograms.

> I/O should be counted separately; Using exceptions to signal invalid
> input to some procedure way up the call stack is indeed not a good
> idea;

Why? It is the sole idea of exception, to postpone handling until reaching
a context where there were more knowledge available.

> in fact, DbC warns you that DbC is not at all about invalid
> input.

Maybe, but as I have explained in my post to Randy, don't want to be get
involved into semantic issues. Those are not my concern. The contracts I
meant will tell nothing about the semantics. They will do merely about a
*possibility* for an exception to propagate. Nothing more.

>>>> There is not that many handlers in a good designed code.
>>> Hear, hear. [Q] Why do we need more exception announcements, then?
>> 
>> Because of the damage an unhandled exception does.
> 
> I don't buy this. Sure, if your program has effects when
> it continues computing using erroneous values,

I does not continue, it crashes!

>>> Will design improve because of subp with exception announcements?
>> 
>> This is a different question. Clearly any language change has certain
>> effect on the programming practices and average design. I cannot foresee
>> how contracts would influence us, programmers.
> 
> The question, 'How does a language feature affect programs?'
> is all that matters because programs are produced by writing
> them in the programming language with a certain set of features.

If you want an answer to this question, then in my humble opinion
contracted exceptions will sufficiently improve quality of Ada programs.
You are welcome to disagree.

>>> If programmers do not handle exceptions properly when they
>>> do not see them in source, will forcing them to handle exceptions
>>> make them handle exceptions _properly_?
>> 
>> Exactly so. They still will have an option to keep on ignoring exceptions.
>> Only if they will announce the program as exception E free, only then, they
>> will be forced to take care of E. Looks reasonable to me.
> 
> I suggest you look at some Java code, then. It might change
> your perspective on programming (not necessarily Java's fault).

We should learn from mistakes and successes of others...

> Therefore, a construct should be such that typical use of the
> construct will help normal programmers writing reasonably good
> programs. (For me this includes being able to understand and change
> the program without a PhD in CS.)

Agreed.
 
> Here is an example of why I think that treating exceptions
> like another formal "flow" of control is not going to work
> in any practical sense.
> 
> packge Subsys is
> 
>     Oops: exception;  -- minor hickup
>     Argh: exception;  -- Can't go on
...
 
> exception
>     when Oops =>
>        -- Oops is o.K., our software is robust
>        null;
>     when Argh =>
>        raise An_Error_Has_Occured;
> end Subsys.Job;
> 
> Now the programmers writing Subsys.P and Subsys.Q decide to
> switch the exceptions raised by F and G respectively.
> There is a chance that Job won't need a different handler
> because the set of exceptions to be handled
> has not changed: {Oops, Argh}.
> But the meaning of the exceptions has changed significantly,
> Oops is now the exception that must be handled but it isn't ...
> 
> I don't see an improvement so far.

1. It is *not* about semantics of exceptions, see above.

2. The program design above (in my view) is fundamentally flawed, because
exceptions are for programming, they are not for debugging.

> So we need a different program! One that enables the compiler
> to notice that the exception announcements have been changed.

What for, if the handling is still same?

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