Re: Exceptions

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

On Mon, 10 Dec 2007 10:20:38 +0100, Georg Bauhaus wrote:

> Do programmers put a block around every procedure call so
> that the proper occurence of Constraint_Error is handled?

Yes if Constraint_Error shall not propagate further. What is the
alternative BTW? To say that it does not propagate, but let it do?

Note that to argue against exception contracts on the basis that handling
exceptions is difficult is a fallacy. It is like to argue that
floating-point type is bad because calculating sine is difficult.

> And will this likelyhood increase once subp declarations
> announce foreseeable exceptions?
> 
>> 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.

>> 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. The goal of software
design is to minimize the damage caused by program execution (the best way
is not to write any programs at all (:-)).

Lesser likelihood of exception propagation is compensated by the damage
inflicted by.

> 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. I can only say that
contracted exceptions are well in Ada spirit.

>> This is probably
>> the reason why people forget to handle exceptions properly. They are not
>> that visible.
> 
> 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 have seen a number of null handlers...
> 
> My guess is that missing else branches or undocumented null "others"
> in case distinctions are a related issue. The issue really is
> handling cases, not announcing them. Every if implies the possibility
> of an else. Still we can have null else branches (or "others" choises).

No, only in absence of a contract. Consider:

function Foo return ... is
begin
   if ... then
      return ...;
   end if;
end Foo;

This is illegal because of the contract to return a value. I hope you do
not propose to make Foo legal because required "else" would spoil so nicely
formatted code? (:-))

Exception non-propagation contracts fall under this category.

> If only the Algol symbol "comment" had been given more emphasis
> in successor languages. A friendly tell-us-what-you-think!
> mechanism is better IMHO than a combination of force together with a
> force absorbing mechanism! (Exception "contracts" together with
> null handlers and the like.)
> 
>    case Traffic_Light is
>       when Red => ... ;
>       when Green => .... ;
>       when others =>
>          comment No comment;
>          null;  -- forces the comment.
>          -- Hypothesis: the comment "No comment" will not
>          -- pass quality control
>    end case;
> 
> Remove "others" from the languge? :-)

The problem here is not others. The problem is the power of a language
construct. Others is harmless if it includes only Blue. It can be damaging
if it does "all other Integers." Ideally the constructs should be as weak
as possible to be able to accomplish the goal. Goto or template solve the
problem but they call the devil who won't go back. So "others" does when it
refers to a set of big cardinality then covered by null-action.

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