Re: Java exception model. Was: Re: Ada Quality and Style book discussion ("_Type" suffix)

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

On Fri, 18 Nov 2005 11:48:46 GMT, Peter C. Chapin wrote:

> Brian May wrote:
> 
>> With respect to his complaint on exception handling - I like the Java
>> model where every exception that can be raised by a function has to be
>> declared - that way you don't have to check for exceptions that don't
>> currently occur - and if the specifications change, the compiler can
>> generate an error to let you know that you may not have considered an
>> exception.
> 
> The problem with Java's model is that it forces the programmer to deal 
> in some way with exceptions that semantically can't happen. Consider
> 
> procedure Outer is
> begin
>    if Some_Complicated_Check then
>      Inner;
>    end if;
> end Outer;
> 
> Suppose procedure Inner raises an exception under certain conditions yet 
> can't do so in the code above because Inner is only executed when the 
> complicated check succeeds. Assume that under those particular 
> conditions, it will never fail. The Java exception model would require 
> us to either handle an exception that will never occur, or declare that 
> Outer might raise an exception that we know it will never raise. Such a 
> declaration will force Outer's callers to also do something about this 
> impossible exception as well, etc, and so forth.

I can't tell for Java, but let consider Ada adopting a contract model of
exceptions. Your reasoning above is flawed. If the designer of Outer knows
that the exception X cannot propagate out of it then it should be:

procedure Outer is
begin
   if Some_Complicated_Check then
      begin
         Inner;
      exception
         when X => -- This is not a state, it is a bug
            raise Program_Error;
      end if;
   end if;
end Outer;

> The example above is simplistic and contrived but it's my belief that in 
> real programs this sort of issue comes up a lot.

I think it is a software design issue. When exceptions and exceptional
states are considered as *valid* states, then there cannot be any good
argument against contract model of exceptions. They belong to a
*functional* part of the program. What is left, are the arguments like - it
is too difficult to implement; there would be too big overhead; I don't
know how to do it right - not much impressive. Alternatively you can say,
OK, exceptions are exclusively for software bugs. But this is also a quite
weak position, because if they are bugs, then why would you like to handle
them? Bugs to be debugged!

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