Re: Ada exceptions. unchecked?

["Gisle Sælensminde" <gisle@apal.ii.uib.no>]

In article <3D08ABBA.C8AF105@raytheon.com>, Mark Johnson wrote:
> Gisle S�lensminde wrote:
>> In article <3D0750F1.7A12342@raytheon.com>, Mark Johnson wrote:
>> [snip - explanation of java exceptions...]
>> > Adding it to Ada at this point would break a lot of code (but also
>> > likely FIX a lot of code when implemented).
>> >   --Mark
>> 
>> Checked exceptions as in Java is in fact a horrible idea. If you assume
>> that the program is designed with error handling in mind from the start,
>> it could work, but in practice you will discover at some point that some
>> lowlevel error condition the highlevel need to handle. In that case
>> all the methods in the entire call tree need to be changed. If the
>> application is sufficiently large, you simply can't do that.
>> 
> I am not so certain if the problem is...
>  - the implementation of checked exceptions in Java is broke
>  - the constraints on implementing code that uses checked exceptions are
> too onerous
> or something else entirely.
> 
> The point you make addresses a typical application problem. You have a
> higher level module attempting to recover from some low level
> implementation detail that should be transparent to it. I can argue that
> the one of the abstractions used to build the application is broken -
> not checked exceptions. Checked exceptions helped you find out that the
> design or implementation is broke - fix it.

That's only true if you assume that you can make a full design of the
whole application in advance. In practice you don't have overview of all
aspects of the application area, and most applications is developed
in an evolutionary manner

One example I know of is a 300.000 SLOC java application where improved
memory handling had to be added, since some JVMs never recovers if a
new fails due to unsufficient memory. Therefore an exception had to be thrown,
so the highlevel could free up memory resources. This was important since
the application should run for weeks/months. The problem was that it was
not possible to add new signatures to tousands of soubroutines in a reasonable
time, and redesign would take even longer time.

The soulution was to subclass an existing excepton, and handle the difference
in the highlevel layer, which is close to the solution sugested by others in
this thread. The solution is in fact an omission of checked exceptions.
  
One of the main problems is that the checked exceptions forces the programer
to take an early choice of what to do with the exceptions. Even you handles
and design this perfectly yourself, you still have to deal with other peoples
code, where you can find code like the following.

try{
  obj.doSomeThing();
}
catch(Exception ex){
   //Remember to insert code to handle this properly.
}

The problem is that exception handling at one layer possibly must be handled
in parts of the program where it does not make sense, and that make programmers
to do such code "to get the job done". My point is that the strictness of
java exceptions is counter-productive.

 
> If THAT was the only problem with checked exceptions in Java, then I
> would argue that the addition of checked exceptions to Ada would be a
> good idea. However, I am not convinced of that at this time.

Java exception is also quite verbose, both in syntax for handling them, and
in the fact that each exception is their own class.

-- 
--
Gisle S�lensminde ( gisle@ii.uib.no )   

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)