Exceptions

Exceptions

[shaunpatterson]

Is there any way to force programmers to catch exception that
your function throws? Something like Java forcing coders to
put try/catch blocks


Thanks
--
Shaun

Re: Exceptions

[tmoran]

>Is there any way to force programmers to catch exception that
>your function throws?
  Do you mean force them to write code like:
begin
  y := func(x);
exception
  when funcs_important_exception=>null; -- ignore unimportant exception
end;

Re: Exceptions

[Gautier]

shaunpatterson@gmail.com wrote:

> Is there any way to force programmers to catch exception that
> your function throws? Something like Java forcing coders to
> put try/catch blocks

Surely you can do it with AdaControl:
http://www.adalog.fr/adacontrol2.htm
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Exceptions

[anon]

with Ada.Text_IO ;
use  Ada.Text_IO ;

procedure p is

  K : integer ;
  
  Test_Error : Exception ;

  --
  -- Returns True  if K is Positive
  --         False if K is Negative
  --
  -- And raises (throw) an exception, if K is Zero
  --
  function F return Boolean is
    begin
      If K < 0 then
        return False ;
      elsif K > 0 then
        return True ;
      else
        raise Test_Error ; -- (throw) an exception
      end if ;
    end F ;


begin

  K := 0 ;

  if F then 
    Put_Line ( "K is a Positive number" ) ;
  else
    Put_Line ( "K is a Negative number" ) ;
  end if ;

exception 
  --
  -- catch a program specific exception
  -- K is Zero.
  --
  when Test_Error =>
    Put_Line ( "K is Zero" ) ;
    Put_Line ( "So, function raised a exception" ) ;

  --
  -- Catch all other excptions
  --
  when others =>
    Put_Line ( "Program raised a exception" ) ;

end p ;


In <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com>, shaunpatterson@gmail.com writes:
>Is there any way to force programmers to catch exception that
>your function throws? Something like Java forcing coders to
>put try/catch blocks
>
>
>Thanks
>--
>Shaun

Re: Exceptions, part 2

[anon]

Forgot, to say there is no GNAT compiler option or standard Ada command 
that will force a programmer to use the "Exception" statement. So it 
is up the the programmer to include the statement unlike Java which 
forces the issue.

In <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com>, shaunpatterson@gmail.com writes:
>Is there any way to force programmers to catch exception that
>your function throws? Something like Java forcing coders to
>put try/catch blocks
>
>
>Thanks
>--
>Shaun

Re: Exceptions

[Dmitry A. Kazakov]

On Thu, 06 Dec 2007 15:24:44 -0600, tmoran@acm.org wrote:

>>Is there any way to force programmers to catch exception that
>>your function throws?

> Do you mean force them to write code like:
> begin
>   y := func(x);
> exception
>   when funcs_important_exception=>null; -- ignore unimportant exception
> end;

Semantics of exception handling is a different story. When a contract is
satisfied, its implementation can still be incorrect.

When "a way to force" reads "exceptions contract", then the answer is no,
there is no way, alas.

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

Re: Exceptions

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Thu, 06 Dec 2007 15:24:44 -0600, tmoran@acm.org wrote:
> 
>>> Is there any way to force programmers to catch exception that
>>> your function throws?
> 
>> Do you mean force them to write code like:
>> begin
>>   y := func(x);
>> exception
>>   when funcs_important_exception=>null; -- ignore unimportant exception
>> end;


> When "a way to force" reads "exceptions contract", then the answer is no,
> there is no way, alas.
> 

Nevertheless, the function can be declared in a package next
to an exception declaration. This should, I think, alarm users
of the package that the subprograms might raise an occurence.
It should also point to who is responsible for catching.
The exception's name can also be chosen to be more specific than
Constraint_Error.


Eiffel's way is to have names for pre- and post-conditions (etc.).
The model is instructive, I think.


   feature {ANY} -- visible to any client

	func (x: INTEGER): INTEGER
		require
			even: x \\ 2 = 0
			sizeable: x.abs > 2
		do
			Result := raises_if_odd (x)  -- o.K.
			Result := at_random(Result)  -- might raise
		ensure
			-- Result is another integer provided some
			-- random number is good;
			-- otherwise, bad things might happen.
		end

   feature {NONE} -- fully private

	raises_if_odd(x: INTEGER): INTEGER
			-- assume x has been tested
		do
			Result := 42 // (x \\ 2 - 1)
		end

	g: RANDOM
	at_random(x: INTEGER): INTEGER
			-- try to produce another integer from `x`
			-- Forces a dangerous operation for this demo
		do
			g.forth
			Result := x // g.item  -- deliberate danger!
		end

Re: Exceptions

[shaunpatterson]

Well that is unfortunate. I use exception handlers when appropriate...
I cant say the
same about the codemonkeys I work with. It'd be nice to force them to
catch.

Thanks

Re: Exceptions

[Gautier]

shaunpatterson@gmail.com wrote:
> Well that is unfortunate. I use exception handlers when appropriate...
> I cant say the same about the codemonkeys I work with. It'd be nice to force them to
> catch.
> 
> Thanks

You can force them to pass their code through AdaControl, with a specific rule 
for that. It would also detect plenty of other mistakes of your monkeys...
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Exceptions

[Adam Beneschan]

On Dec 6, 7:00 am, shaunpatter...@gmail.com wrote:
> Is there any way to force programmers to catch exception that
> your function throws?

Not in Ada.  If you're looking for, say, a pragma that you can put on
a subprogram declaration to tell the compiler to reject any code that
calls the subprogram in a place not governed by an exception handler
for a specified exception---that's an interesting idea, and maybe if
there's enough interest it could be added to a future revision of Ada,
probably Annex H.  I don't see any problem with a particular compiler
vendor implementing a pragma like that, though, although of course it
would be non-portable; perhaps you could ask your vendor if they'd be
willing to implement something like that.  It would probably not be
too difficult to implement.

                                -- Adam

Re: Exceptions

[Simon Wright]

shaunpatterson@gmail.com writes:

> Well that is unfortunate. I use exception handlers when
> appropriate...  I cant say the same about the codemonkeys I work
> with. It'd be nice to force them to catch.

Someone upthread pointed out that forcing people to catch will often
mean that they just suppress the exception, usually with disastrous
results. I'd rather let unexpected exceptions propagate to some outer
wrapper.

The comment accompanying the subprogram spec should say 'may raise
...'.

I've suggested in the past that a package/suite should only
deliberately propagate exceptions that make sense in the context of
the package/suite -- in other words, don't propagate
GNAT.Sockets.Socket_Error if you're a web client and what you mean is
that you've lost connection with a server.

I'm not so sure about this now, because it makes it very awkward to
debug (we usually just get the traceback, core dumps tricky on the
target board). What I'd like is to be able to propagate my exception
with the original callback info -- very compiler-specific, I would
think.

Re: Exceptions

[Simon Wright]

Adam Beneschan <adam@irvine.com> writes:

> On Dec 6, 7:00 am, shaunpatter...@gmail.com wrote:
>> Is there any way to force programmers to catch exception that
>> your function throws?
>
> Not in Ada.  If you're looking for, say, a pragma that you can put
> on a subprogram declaration to tell the compiler to reject any code
> that calls the subprogram in a place not governed by an exception
> handler for a specified exception---that's an interesting idea, and
> maybe if there's enough interest it could be added to a future
> revision of Ada, probably Annex H.  I don't see any problem with a
> particular compiler vendor implementing a pragma like that, though,
> although of course it would be non-portable; perhaps you could ask
> your vendor if they'd be willing to implement something like that.
> It would probably not be too difficult to implement.

I think this would be a very bad idea. I don't want to be forced to
deal with the exception 'here' when it would be better handled by my
caller.

I suppose we could have 'pragma Propagates' but it seems like a lot of
work for little gain (what _is_ the gain?)

--S

Re: Exceptions

[Adam Beneschan]

On Dec 7, 10:59 am, Simon Wright <simon.j.wri...@mac.com> wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > On Dec 6, 7:00 am, shaunpatter...@gmail.com wrote:
> >> Is there any way to force programmers to catch exception that
> >> your function throws?
>
> > Not in Ada.  If you're looking for, say, a pragma that you can put
> > on a subprogram declaration to tell the compiler to reject any code
> > that calls the subprogram in a place not governed by an exception
> > handler for a specified exception---that's an interesting idea, and
> > maybe if there's enough interest it could be added to a future
> > revision of Ada, probably Annex H.  I don't see any problem with a
> > particular compiler vendor implementing a pragma like that, though,
> > although of course it would be non-portable; perhaps you could ask
> > your vendor if they'd be willing to implement something like that.
> > It would probably not be too difficult to implement.
>
> I think this would be a very bad idea. I don't want to be forced to
> deal with the exception 'here' when it would be better handled by my
> caller.

I wouldn't want that either.  But this seems like a "coding standard"
sort of thing that organizations sometimes impose to force their less-
experienced programmers to be more careful.  I know I'd grumble if I
had to adhere to a standard like that, but some organizations seem to
think it's a good thing anyway.  I can see how a pragma like this
could be useful in that sort of context.

Hopefully the OP is talking about writing a function for internal use
by other programmers in the same organization, not one that would be
part of a library to be released to the public or for use by
customers.  If it's either of the last two, then it's definitely a bad
idea---it shouldn't be any of his business how other outside users
deal with exceptions.  Unless, of course, the exception isn't really
an exceptional condition but rather a "normal result" returned in a
different way, which I think is a really, really bad idea.

                              -- Adam

Re: Exceptions

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:uvkiadiwrfh2.wi288ebeq18y.dlg@40tude.net...
...
> When "a way to force" reads "exceptions contract", then the answer is no,
> there is no way, alas.

The ARG has discussed "exception contracts" a couple of times, but there
didn't seem that there was enough interest. The problem was mainly that they
simply don't look very valuable (for Ada, I'm not going to comment on other
languages) when the details are looked at, and they'd be fairly complex to
define. The biggest issue is compatibility, of course (since Ada has had
exceptions from the beginning, and never has had contracts, they'd have to
be optional - but it's not clear if optional contracts are worth much).
Another one is what to do if a contract is violated. The obvious answer of
raising Program_Error doesn't do anything other than lose information about
an exception, so that isn't very satisfying. (Static detection of contract
violations isn't possible in general because the contracts have to be
optional.) And then there is the problem of predefined exceptions like
Storage_Error -- every routine *can* raise Storage_Error, although few
*expect* to do so (if they don't allocate memory). Does that have to be
included in every contract? If so, that's ugly, and if not, the oddity of
not quite a contract is unpleasant. And there are more issues: the
maintenance cascade when an exception is added or removed; what about
call-back routines (think Process in the Containers library); and so on.

I'm sure that something could be worked out, but it seemed like there were
more valuable things to do.

                                   Randy.

Re: Exceptions

[Stephen Leake]

shaunpatterson@gmail.com writes:

> Is there any way to force programmers to catch exception that
> your function throws? Something like Java forcing coders to
> put try/catch blocks

What do you mean by "force"?

If your function throws an exception, in Ada or Java, the runtime
semantics define what happens.

If a caller of your function wants to handle the exception, they can. 

If they don't want to, they can do that as well.

What is the use case you have in mind?

-- 
-- Stephe

Re: Exceptions

[Stephen Leake]

shaunpatterson@gmail.com writes:

> Well that is unfortunate. I use exception handlers when appropriate...
> I cant say the
> same about the codemonkeys I work with. It'd be nice to force them to
> catch.

That's up to the project managers; coding style is enforced by code
reviews.

-- 
-- Stephe

Contracted exceptions for Ada (was: Exceptions)

[Dmitry A. Kazakov]

On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:uvkiadiwrfh2.wi288ebeq18y.dlg@40tude.net...
> ...
>> When "a way to force" reads "exceptions contract", then the answer is no,
>> there is no way, alas.
> 
> The ARG has discussed "exception contracts" a couple of times, but there
> didn't seem that there was enough interest. The problem was mainly that they
> simply don't look very valuable

My observation is that a big deal of debugging Ada code is about tracing
down unexpected exceptions. I cannot give any figures, but it is extremely
frequent that a bug manifests itself as an exception propagation. Typically
Constraint_Error propagates where you didn't expect it. So the temptation
is to catch most of such things at compile time.

(Maybe a wild guess, but this could save Ariane V. A program assumed
Constraint_Error exception free was recompiled for the hardware where that
was not the case.)

> (for Ada, I'm not going to comment on other
> languages) when the details are looked at, and they'd be fairly complex to
> define. The biggest issue is compatibility, of course (since Ada has had
> exceptions from the beginning, and never has had contracts, they'd have to
> be optional - but it's not clear if optional contracts are worth much).

I don't see a problem here. Legacy code will have an implied exception
contract stating that anything may propagate out.

> Another one is what to do if a contract is violated. The obvious answer of
> raising Program_Error doesn't do anything other than lose information about
> an exception, so that isn't very satisfying.

Yes, in my view exception contracts have to be static. (It makes no sense
to have run-time exception contracts. As well as any other contracts, there
is no any authority body to judge contract violations at run-time.)

> (Static detection of contract
> violations isn't possible in general because the contracts have to be
> optional.) 

It is not optional it is "any exception may propagate."

> And then there is the problem of predefined exceptions like
> Storage_Error -- every routine *can* raise Storage_Error, although few
> *expect* to do so (if they don't allocate memory). Does that have to be
> included in every contract?

That's up to the programmer's choice. If he chooses to contract
Storage_Error as non-propagating, then be it so.

I think there exist ways to provide much better control over Storage_Error
than we have and without distributed overhead. The contract on
Storage_Error would be conditional. That is - the subroutine Foo does not
raise Storage_Error if there is N1..Nn bytes of free space in the storage
pools P1..Pn. Such contracts are conservatively checkable. Of course, the
actual pool states themselves will never be checked at run-time (following
the principle above).

In extraordinary cases the programmer should have a option to give his word
that a subprogram or a part of require no more than N bytes. That would be
an "unchecked Storage_Error contract", by analogy to Unchecked_Conversion:

function Recursive (...) return ... is
   -- I give my word that Recursive uses only 10K of stack
begin
   if ... then
      return Recursive (...);
   else
      return ...;
   end if;
end Recursive;

> If so, that's ugly, and if not, the oddity of
> not quite a contract is unpleasant. And there are more issues: the
> maintenance cascade when an exception is added or removed;

No problem. Exception contracts should be inheritable. File open would say
"I raise this and that and also anything disk driver does." (I remember
Robert Duff proposed that once.)

> what about
> call-back routines (think Process in the Containers library); and so on.

Conditional contracts: container's Forall is exception E free if Process
is.

> I'm sure that something could be worked out, but it seemed like there were
> more valuable things to do.

Like multiple dispatch? (:-)) 

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

Re: Exceptions

[Peter C. Chapin]

Randy Brukardt wrote:

> The ARG has discussed "exception contracts" a couple of times, but there
> didn't seem that there was enough interest...

These sort of issues have also been discussed at length in the C++
community, mostly in the context of why C++'s exception specifications
were a mistake. In those discussions I've heard many reasonable people
also express the opinion that Java's statically enforced exception
specifications were a bad idea.

The problem often quoted is that there are cases where an exception
looks like it could happen, but for reasons the compiler doesn't know
can't actually happen. As a simple example consider the code fragment

if Has_Acceptable_Value(X) then
  P1(X);
  P2(X);
  P3(X):
end if;

Suppose P1 raises an exception if X is negative. Depending on what
Has_Acceptable_Value does, it is quite possible that can't happen in the
code above. If you specify exception contracts the way Java did, then
the programmer in the above case ends up having to handle an exception
that won't happen or claim to propagate and exception that won't get
propagated. Either option is undesirable.

While one could argue that it is safest to assume the exception might
happen anyway (since Has_Acceptable_Value might change or be incorrect),
forcing empty handlers all over the place to cover such possibilities
doesn't seem right either. In fact, such handlers would probably eat the
unexpected exceptions and actually prevent buggy from being discovered
and fixed. In this respect exception contracts might actually reduce
reliability rather than promote it.

C++ checks exception specifications at run time, but then it's hard to
know what to do when a check fails. C++ throws a different exception in
that case, but that doesn't really solve anything as far as I can see.
The C++ community seems to have concluded that being able to declare a
function as throwing no exceptions is potentially useful, but that there
is little point in trying to go beyond that.

It seems like Ada got this right by not attempting to provide language
based exception contracts. Adding such contracts to Ada might well be
taking the language in the wrong direction.

Peter

Re: Exceptions

[Dmitry A. Kazakov]

On Sat, 08 Dec 2007 07:26:21 -0500, Peter C. Chapin wrote:

> The problem often quoted is that there are cases where an exception
> looks like it could happen, but for reasons the compiler doesn't know
> can't actually happen. As a simple example consider the code fragment
> 
> if Has_Acceptable_Value(X) then
>   P1(X);
>   P2(X);
>   P3(X):
> end if;
> 
> Suppose P1 raises an exception if X is negative. Depending on what
> Has_Acceptable_Value does, it is quite possible that can't happen in the
> code above. If you specify exception contracts the way Java did, then
> the programmer in the above case ends up having to handle an exception
> that won't happen or claim to propagate and exception that won't get
> propagated. Either option is undesirable.

The problem here is not exception contracts but firstly lack of subtypes in
C++. Ada has subtypes, so the code above could be rewritten [properly]:

if X in Safe_For_P1 then
   declare
      Checked_X : Safe_For_P1 renames X;
   begin
      P1 (Checked_X); -- This does not raise exception
 
The actual problem for Ada is that there is no syntax sugar for "if X in S
then X indeed in S" (:-)) This is not about exceptions, we also do

if Ptr /= null then
   Foo (Ptr.all);

No way to assure that Ptr cannot be null in Ptr.all to require the compiler
to drop checks.

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

Re: Exceptions

[Peter C. Chapin]

Dmitry A. Kazakov wrote:

> The problem here is not exception contracts but firstly lack of subtypes in
> C++. Ada has subtypes, so the code above could be rewritten [properly]:
> 
> if X in Safe_For_P1 then
>    declare
>       Checked_X : Safe_For_P1 renames X;
>    begin
>       P1 (Checked_X); -- This does not raise exception

Here is my example again:

if Has_Acceptable_Value(X) then
  P1(X);
end if;

What if Has_Acceptable_Value(X) returns true if X is prime... or a
positive power of two? I don't believe you can use Ada subtypes to
express conditions like that---or indeed many other possibilities.
However, since primes (or positive powers of two, etc) aren't negative,
my earlier point is still valid. The above code won't raise the
exception in P1 (assume P1 only raises for negative arguments) so
handling it or claiming to propagate it is a waste of resources and
misleading.

Peter

Re: Exceptions

[Dmitry A. Kazakov]

On Sat, 08 Dec 2007 13:01:13 -0500, Peter C. Chapin wrote:

> Dmitry A. Kazakov wrote:
> 
>> The problem here is not exception contracts but firstly lack of subtypes in
>> C++. Ada has subtypes, so the code above could be rewritten [properly]:
>> 
>> if X in Safe_For_P1 then
>>    declare
>>       Checked_X : Safe_For_P1 renames X;
>>    begin
>>       P1 (Checked_X); -- This does not raise exception
> 
> Here is my example again:
> 
> if Has_Acceptable_Value(X) then
>   P1(X);
> end if;
> 
> What if Has_Acceptable_Value(X) returns true if X is prime... or a
> positive power of two? I don't believe you can use Ada subtypes to
> express conditions like that---or indeed many other possibilities.

Yes, but it that case very design of P1 is in question. Why the set of
values where P1 is defined does not constitute some semantically integral
body (like a subtype)? P1 is an operation of what? Maybe I would not use
exceptions in P1, or else mark the caller of P1 as propagating the
exception of P1.

> However, since primes (or positive powers of two, etc) aren't negative,
> my earlier point is still valid. The above code won't raise the
> exception in P1 (assume P1 only raises for negative arguments) so
> handling it or claiming to propagate it is a waste of resources and
> misleading.

On the contrary, if I decided to use an exception in P1, then I would see
it as an advantage that the language would force me to put a handler around
P1, because semantic relation between Has_Acceptable_Value and P1 is not
obvious since there is no subtype. Later me or another maintainer of the
code will certainly forget about any relation between them and mistakenly
remove if Has_Acceptable_Value.
 
-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Contracted exceptions for Ada

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote:
>
>> Another one is what to do if a contract is violated. The obvious answer of
>> raising Program_Error doesn't do anything other than lose information about
>> an exception, so that isn't very satisfying.
>
> Yes, in my view exception contracts have to be static. 

The only way to statically enforce exception contracts is to use SPARK
Ada (http://www.praxis-his.com/sparkada/). SPARK Ada does do exactly
that (among other things); it also signficantly restricts the Ada
language to a manageable subset.

So if you like exception contracts, use SPARK Ada.

If you like all the things SPARK Ada leaves out (I don't have the
current list handy; it doesn't seem to be on the web site), use
standard Ada.

-- 
-- Stephe

Re: Exceptions

[Stephen Leake]

"Peter C. Chapin" <pchapin@sover.net> writes:

> Dmitry A. Kazakov wrote:
>
>> The problem here is not exception contracts but firstly lack of subtypes in
>> C++. Ada has subtypes, so the code above could be rewritten [properly]:
>> 
>> if X in Safe_For_P1 then
>>    declare
>>       Checked_X : Safe_For_P1 renames X;
>>    begin
>>       P1 (Checked_X); -- This does not raise exception
>
> Here is my example again:
>
> if Has_Acceptable_Value(X) then
>   P1(X);
> end if;
>
> What if Has_Acceptable_Value(X) returns true if X is prime... or a
> positive power of two? I don't believe you can use Ada subtypes to
> express conditions like that---or indeed many other possibilities.

Right. You have to use SPARK Ada. 

-- 
-- Stephe

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 05:22:44 -0500, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote:
>>
>>> Another one is what to do if a contract is violated. The obvious answer of
>>> raising Program_Error doesn't do anything other than lose information about
>>> an exception, so that isn't very satisfying.
>>
>> Yes, in my view exception contracts have to be static. 
> 
> The only way to statically enforce exception contracts is to use SPARK
> Ada (http://www.praxis-his.com/sparkada/). SPARK Ada does do exactly
> that (among other things); it also signficantly restricts the Ada
> language to a manageable subset.

(I doubt that limitations of SPARK are caused by contracted exceptions. It
just does right what Ada didn't.)

> So if you like exception contracts, use SPARK Ada.
> 
> If you like all the things SPARK Ada leaves out (I don't have the
> current list handy; it doesn't seem to be on the web site), use
> standard Ada.

This does not answer the questions, which are two:

1. Are contracted exceptions any good?
(If they are not then SPARK isn't as well)

2. Can Ada have them?
(If not then why SPARK does?)

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

Re: Exceptions

[Peter C. Chapin]

Dmitry A. Kazakov wrote:

>> if Has_Acceptable_Value(X) then
>>   P1(X);
>> end if;
>>
>> What if Has_Acceptable_Value(X) returns true if X is prime... or a
>> positive power of two? I don't believe you can use Ada subtypes to
>> express conditions like that---or indeed many other possibilities.
> 
> Yes, but it that case very design of P1 is in question. Why the set of
> values where P1 is defined does not constitute some semantically integral
> body (like a subtype)?

Well, my example above is a bit contrived. Let's consider a couple of
more realistic examples:

1. X is a string. Has_Acceptable_Value returns true if X is the name
field of some record in a database. The procedure P1 executes some
string handling algorithm that happens to not be meaningful for empty
strings. Thus P1 raises an exception if given such a string. Yet, due to
database constraints (let's say), any X that causes Has_Acceptable_Value
to return true won't be empty so the exception never arises.

2. X is an abstract type representing an XML document.
Has_Acceptable_Value returns true if X is valid according to its
declared schema. P1 does some XML processing but it assumes the document
given to it is well formed and raises exceptions if that is not the
case. Since valid documents are also well formed, those exceptions won't
occur once Has_Acceptable_Value has signed off on X. Indeed, this is one
 of the main reasons why validating documents before processing them is
desirable: it simplifies later error handling.

If I understand what you are saying, one would need to define a subtype
of strings that contains all strings but the empty string (for #1) or a
subtype of my abstract type that contains all valid XML documents (for
#2). Can those things be expressed using Ada subtypes? I suppose it
could be done using type derivation, but is invoking that machinery
really better than just ignoring the possibility that P1 will raise and
letting any unexpected exceptions propagate in the usual way?

The issue is particularly acute when there is an else clause on the if.

if Is_Valid_XML(X) then
  Process_Document(X);
else
  Log_Bad_Document(X);
end if;

Suppose the above is inside a loop that runs over a collection of
documents. Do we really want to include a handler for
Not_Well_Formed_Exception in this procedure just because the contract on
Process_Document says it might raise such an exception? Do we really
want to claim that we propagate that exception when we clearly don't?

You might say that in a careful program (for example in a high integrity
program) unexpected exceptions should not be treated in such a cavalier
manner. I would agree with that. The question is should the language
attempt to force that degree of care on all programs? It's a balance
between usability and safety. As with all things related to security,
overly aggressive policies can backfire when people feel the need to do
silly things to work around them. I suppose at the end of the day it's
really just a matter of taste... which is what makes debates like this
possible. :-)

Peter

Re: Exceptions

[Peter C. Chapin]

Stephen Leake wrote:

> Right. You have to use SPARK Ada. 

I could be wrong, but I was under the impression that the SPARK subset
disallowed exceptions entirely because they are too difficult to
analyze. If so, the only exceptions that might occur in a SPARK program
are the predefined ones; and as I understand it the SPARK tool set gives
you a way to prove, under certain circumstances, that even those will
not occur.

Not being a heavy SPARK user, however, I could be off base here.

Peter

Re: Exceptions

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 07:40:45 -0500, Peter C. Chapin wrote:

> Dmitry A. Kazakov wrote:
> 
>>> if Has_Acceptable_Value(X) then
>>>   P1(X);
>>> end if;
>>>
>>> What if Has_Acceptable_Value(X) returns true if X is prime... or a
>>> positive power of two? I don't believe you can use Ada subtypes to
>>> express conditions like that---or indeed many other possibilities.
>> 
>> Yes, but it that case very design of P1 is in question. Why the set of
>> values where P1 is defined does not constitute some semantically integral
>> body (like a subtype)?
> 
> Well, my example above is a bit contrived. Let's consider a couple of
> more realistic examples:
> 
> 1. X is a string. Has_Acceptable_Value returns true if X is the name
> field of some record in a database. The procedure P1 executes some
> string handling algorithm that happens to not be meaningful for empty
> strings. Thus P1 raises an exception if given such a string. Yet, due to
> database constraints (let's say), any X that causes Has_Acceptable_Value
> to return true won't be empty so the exception never arises.

Then I would propose:

begin
   P1 (X);
exception
   when Empty_String_Error =>
       -- do something else
end;

If the point is that exception propagation is too expensive for the caller
of P1 then again, why wasn't it for P1? Bad design?

> 2. X is an abstract type representing an XML document.
> Has_Acceptable_Value returns true if X is valid according to its
> declared schema. P1 does some XML processing but it assumes the document
> given to it is well formed and raises exceptions if that is not the
> case. Since valid documents are also well formed, those exceptions won't
> occur once Has_Acceptable_Value has signed off on X. Indeed, this is one
>  of the main reasons why validating documents before processing them is
> desirable: it simplifies later error handling.

Isn't this indeed a waste of resources? Validation is performed twice, once
in Has_Acceptable_Value and once in P1! Isn't this design actually based on
a presumption that P1 does something wrong, while Has_Acceptable_Value
would do it right? Wouldn't it better just to fix P1? And for all, I bet
that exception propagation in most cases will be far more efficient than an
extra document parsing.

> If I understand what you are saying, one would need to define a subtype
> of strings that contains all strings but the empty string (for #1) or a
> subtype of my abstract type that contains all valid XML documents (for
> #2). Can those things be expressed using Ada subtypes? I suppose it
> could be done using type derivation, but is invoking that machinery
> really better than just ignoring the possibility that P1 will raise and
> letting any unexpected exceptions propagate in the usual way?

My point is that if there exist problems then they lie by possible
weaknesses of the language subtyping system rather than by contracts for
exceptions.

> The issue is particularly acute when there is an else clause on the if.
> 
> if Is_Valid_XML(X) then
>   Process_Document(X);
> else
>   Log_Bad_Document(X);
> end if;
> 
> Suppose the above is inside a loop that runs over a collection of
> documents. Do we really want to include a handler for
> Not_Well_Formed_Exception in this procedure just because the contract on
> Process_Document says it might raise such an exception? Do we really
> want to claim that we propagate that exception when we clearly don't?

I want to propagate it. If the design foresaw exception propagation (and
contract says so), then I just handle that exception explicitly. To me

begin
   Process_Document (X);
exception
   when Reason : Format_Error =>
      Log_Bad_Document (Reason);
end;

is much cleaner and also more efficient. If some extra analysis of X has to
done then I would do it in the exception handler after the problem has
manifested itself.

The universal principle is never run ahead of the locomotive... (:-))

> You might say that in a careful program (for example in a high integrity
> program) unexpected exceptions should not be treated in such a cavalier
> manner. I would agree with that. The question is should the language
> attempt to force that degree of care on all programs?

YES! Otherwise I would use Visual Basic. (:-))

> It's a balance
> between usability and safety. As with all things related to security,
> overly aggressive policies can backfire when people feel the need to do
> silly things to work around them. I suppose at the end of the day it's
> really just a matter of taste... which is what makes debates like this
> possible. :-)

Talking about balance. It is not about high integrity applications. In
recent times I have been using a lot of GTK+ (under GtkAda). I cannot tell
for AdaCore people developing GPS, but as for me, GTK+ makes me sick.
Roughly 90% of all errors I spent the debugging time on was about
exceptions propagating from Ada into GTK and then crashing it. It is a
mess, and there is no any way to deal with that, because GTK+ is not Ada
and its design contradicts to very foundations of. Analysis of these cases
clearly shows that these bugs could be caught at compile time if we had
exception contracts. I don't see how lacking it could add any usability. It
does otherwise.

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

Re: Contracted exceptions for Ada (was: Exceptions)

[Martin Krischik]

Dmitry A. Kazakov wrote:

> (Maybe a wild guess, but this could save Ariane V. A program assumed
> Constraint_Error exception free was recompiled for the hardware where that
> was not the case.)

My understanding is that the system was brought down by an unexpected
hardware exception - i.E. one which the CPU's floating point unit
generated.

See: http://en.wikipedia.org/wiki/Ariane_5#Launch_history

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Exceptions

[Peter C. Chapin]

Dmitry A. Kazakov wrote:

> Then I would propose:
> 
> begin
>    P1 (X);
> exception
>    when Empty_String_Error =>
>        -- do something else
> end;

I only want X to contain a name from the database. I have to check for
that someplace regardless of what P1 wants to do. Checking for it inside
P1 doesn't work because P1 is a general purpose string handling
algorithm that knows nothing about my application.

> Isn't this indeed a waste of resources? Validation is performed twice, once
> in Has_Acceptable_Value and once in P1!

In this example P1 doesn't validate. It just assumes the document is
valid and skips as much error handling as possible. However P1, or
subprograms it calls, might have the potential of raising a variety of
exceptions, including perhaps C_E if P1 is inadvertently given an
invalid document.

In XML based applications I've written, I validate the document once and
then let the rest of the program just assume it is valid. This means
there are all kinds of error situations I can ignore because they aren't
possible in a valid document. This lets me abbreviate not just one
procedure (like P1), but many procedures.

Peter

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> (Maybe a wild guess, but this could save Ariane V. A program assumed
>> Constraint_Error exception free was recompiled for the hardware where that
>> was not the case.)
> 
> My understanding is that the system was brought down by an unexpected
> hardware exception - i.E. one which the CPU's floating point unit
> generated.

Yes, and that would be detected by the compiler:

   function Integer (X : Float) return Integer;

which was contracted as exception-free on one platform will not be on
another. So the compiler would reject either its implementation that raises
Constraint_Error or else its use contracted as Constraint_Error-free. So
the idea.

(Contracted exceptions would mean a damn LOT of work for the compiler
vendors.)

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

Re: Contracted exceptions for Ada

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote:
>
>> Dmitry A. Kazakov wrote:
>> 
>>> (Maybe a wild guess, but this could save Ariane V. A program assumed
>>> Constraint_Error exception free was recompiled for the hardware where that
>>> was not the case.)
>> 
>> My understanding is that the system was brought down by an unexpected
>> hardware exception - i.E. one which the CPU's floating point unit
>> generated.
>
> Yes, and that would be detected by the compiler:
>
>    function Integer (X : Float) return Integer;
>
> which was contracted as exception-free on one platform will not be on
> another. So the compiler would reject either its implementation that raises
> Constraint_Error or else its use contracted as Constraint_Error-free. So
> the idea.

I don't see how the compiler/platform in use has anything to do with
this.

    In Ariane IV the maximum horizontal velocity is X.

    Therefore we can convert the hardware input to this-type without
    worrying about overflow.

    Therefore any exception will be caused by hardware error.

seems a proper analysis for Ariane IV; reusing precisely the same
software/platform in an environment where the maximum horizontal
velocity was much larger than X is an error that no amount of
*software* engineering is going to fix.

Re: Contracted exceptions for Ada

[Martin Krischik]

Dmitry A. Kazakov wrote:

> On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> (Maybe a wild guess, but this could save Ariane V. A program assumed
>>> Constraint_Error exception free was recompiled for the hardware where
>>> that was not the case.)
>> 
>> My understanding is that the system was brought down by an unexpected
>> hardware exception - i.E. one which the CPU's floating point unit
>> generated.
> 
> Yes, and that would be detected by the compiler:
> 
>    function Integer (X : Float) return Integer;
> 
> which was contracted as exception-free on one platform will not be on
> another. So the compiler would reject either its implementation that
> raises Constraint_Error or else its use contracted as
> Constraint_Error-free. So the idea.
> 
> (Contracted exceptions would mean a damn LOT of work for the compiler
> vendors.)

I forgot to mention mentioned that they used pragma Suppress to speed thing
up (the old 'pedia article mentioned that). With pragma Suppress  in place
the HW-exception was never converted into an Ada-exception.

Even the best exception handling won't help if you switch it off :-( .

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Exceptions

[Robert A Duff]

tmoran@acm.org writes:

>>Is there any way to force programmers to catch exception that
>>your function throws?
>   Do you mean force them to write code like:
> begin
>   y := func(x);
> exception
>   when funcs_important_exception=>null; -- ignore unimportant exception
> end;

I've heard that this is a common problem in Java code.
Compiler complains, so the programmer puts in an
exception-ignoring handler -- probably without any
comment explaining why.

But I don't get it.  If you think a certain exception
is impossible in a certain case, and the compiler
insists on a handler, the obvious thing to do
is raise an unchecked exception.  In Ada:

    when Funcs_Important_Exception =>
        -- <comment explaining why this can never happen>
        raise Program_Error;

Why on earth would anybody write "null;" there?!

I don't blame the Java language design for this problem.

- Bob

Re: Exceptions

[Robert A Duff]

Simon Wright <simon.j.wright@mac.com> writes:

> I think this would be a very bad idea. I don't want to be forced to
> deal with the exception 'here' when it would be better handled by my
> caller.

But this would only apply to some exceptions.  If you don't want to be
"forced", use an unchecked exception.

I think there are some mistakes in the Java design for exceptions, but I
don't think the whole idea of exception contracts is bad.

- Bob

Re: Exceptions

[Robert A Duff]

"Peter C. Chapin" <pchapin@sover.net> writes:

> 2. X is an abstract type representing an XML document.
> Has_Acceptable_Value returns true if X is valid according to its
> declared schema. P1 does some XML processing but it assumes the document
> given to it is well formed and raises exceptions if that is not the
> case. Since valid documents are also well formed, those exceptions won't
> occur once Has_Acceptable_Value has signed off on X. Indeed, this is one
>  of the main reasons why validating documents before processing them is
> desirable: it simplifies later error handling.

Right.  A similar example is a compiler.  E.g. in GNAT, the semantic
analysis phase assumes that the tree produced by the parser is
syntactically correct.  And the code generator assumes that the
program is legal.

> Suppose the above is inside a loop that runs over a collection of
> documents. Do we really want to include a handler for
> Not_Well_Formed_Exception in this procedure just because the contract on
> Process_Document says it might raise such an exception?

Well, we at least want a comment saying why the exception that "might"
be raised will not be raised in this case.  And "when Blah => raise
Bug; -- ..." seems like a good way to say that.

>...Do we really
> want to claim that we propagate that exception when we clearly don't?

No.  That would spread noise around the whole program.

> You might say that in a careful program (for example in a high integrity
> program) unexpected exceptions should not be treated in such a cavalier
> manner. I would agree with that. The question is should the language
> attempt to force that degree of care on all programs? It's a balance
> between usability and safety. As with all things related to security,
> overly aggressive policies can backfire when people feel the need to do
> silly things to work around them. I suppose at the end of the day it's
> really just a matter of taste... which is what makes debates like this
> possible. :-)

How can it be a matter of taste?  Checked exceptions either improve the
code or they don't.  Maybe it depends on the application area.  But I
don't see how it can depend on taste.

- Bob

Re: Contracted exceptions for Ada

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> No problem. Exception contracts should be inheritable. File open would say
> "I raise this and that and also anything disk driver does." (I remember
> Robert Duff proposed that once.)

I think what I proposed was more like what you say below:

>> what about
>> call-back routines (think Process in the Containers library); and so on.
>
> Conditional contracts: container's Forall is exception E free if Process
> is.

Right -- an iterator needs to be able to say "I can raise anything
raised by the loop-body procedure that is passed in to me."
That's one thing missing from Java, which makes exception
contracts more painful than they need to be.  Passing a procedure to an
iterator causes the compiler to lose useful information.

I think preconditions could help a lot in this general area -- instead
of saying "I might raise Divide_By_Zero" on the divide procedure, one
can specify exactly what circumstances cause that exception --
Divide_By_Zero will be raised if and only if you try to divide by zero.
Then if at the call site, you divide by X, and X is Positive, there's
no need for a handler.  Unfortunately, there's no Non_Zero subtype.

- Bob

Re: Exceptions

[Georg Bauhaus]

Robert A Duff wrote:

>     when Funcs_Important_Exception =>
>         -- <comment explaining why this can never happen>
>         raise Program_Error;
> 
> Why on earth would anybody write "null;" there?!
> 

"We know that when this library routine complains,
it doesn't concern us. Besides, why should we pester
the customer or the user with messages and tracebacks that
do not matter?" (In some cultures, openly announcing errors
is not the preferred strategy  ;-)

The idea is that the frame of reference for inventing
the name "Funcs_Important_Exception" is somebody else's.

The source code equivalent of this Don't Care is the missing
comment, quite consequently---even if at another level of
reasoning.

Re: Exceptions

[Georg Bauhaus]

Robert A Duff wrote:
> Simon Wright <simon.j.wright@mac.com> writes:
> 
>> I think this would be a very bad idea. I don't want to be forced to
>> deal with the exception 'here' when it would be better handled by my
>> caller.
> 
> But this would only apply to some exceptions.  If you don't want to be
> "forced", use an unchecked exception.
> 
> I think there are some mistakes in the Java design for exceptions, but I
> don't think the whole idea of exception contracts is bad.
> 
> - Bob

When Robert Dewar talked about exceptions at MIT (I think, that's
from memory of a video recording), one of his arguments was that
you don't want to write cascades of conditionals for handling
return values (being either returned values or failure indicators)
---because that's a mess.

Now, when we have a sequence of statements in a block,

   P1(X); P2(X); ... ; Pn(X, Y);

then what will be the average number of exception handlers
for this block? Involving how many different exceptions?
We would soon arrive at a complicated roughly O(N) size comb
of exception choices and Pk-exceptions covered in each handler.
Each handler possibly involving conditionals for Pk's and Pj's.
I see this as a likely consequence once Ada people start trying
to formally cover the exceptional.

How would that be an improvement and not just the return code
mess again?

(And it smells of using state machines to once again try
to apply AI to things we didn't think of.)

Re: Contracted exceptions for Ada

[Stefan Lucks]

> no need for a handler.  Unfortunately, there's no Non_Zero subtype.

I am afraid, a non-zero subtype would move the problem around, rather than 
solve it. The exception not raised by X/Y might then be raised before, 
when you compute Y:=A-B.

On a second look, this might actually be useful better diagnostics. The 
exception is raised closer to the point where the faulty value (the zero 
Y) is created, rather than, perhaps, much later.


So long


-- 
Stefan Lucks      (moved to Bauhaus-University Weimar, Germany)
 		       <Stefan.Lucks at medien.uni-weimar.de>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 18:39:31 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>> 
>>>> (Maybe a wild guess, but this could save Ariane V. A program assumed
>>>> Constraint_Error exception free was recompiled for the hardware where that
>>>> was not the case.)
>>> 
>>> My understanding is that the system was brought down by an unexpected
>>> hardware exception - i.E. one which the CPU's floating point unit
>>> generated.
>>
>> Yes, and that would be detected by the compiler:
>>
>>    function Integer (X : Float) return Integer;
>>
>> which was contracted as exception-free on one platform will not be on
>> another. So the compiler would reject either its implementation that raises
>> Constraint_Error or else its use contracted as Constraint_Error-free. So
>> the idea.
> 
> I don't see how the compiler/platform in use has anything to do with
> this.
> 
>     In Ariane IV the maximum horizontal velocity is X.
> 
>     Therefore we can convert the hardware input to this-type without
>     worrying about overflow.

Hardware input had a type different from one used later in the control
circle, because it needed to be converted. So what was the contract of that
conversion?

>     Therefore any exception will be caused by hardware error.

The article mentioned by Martin talks about floating point to integer
conversion. Was the conversion programmed in Ada? Probably it wasn't. Then
I can only wonder why people keep on talking about "Ada fault"...

> seems a proper analysis for Ariane IV; reusing precisely the same
> software/platform in an environment where the maximum horizontal
> velocity was much larger than X is an error that no amount of
> *software* engineering is going to fix.

My point is that the fault could be detected (assuming that conversion was
in Ada), under the condition that the compiler vendor would not make the
same mistake while porting the compiler... (:-))

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

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 20:04:44 +0100, Martin Krischik wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>>> (Maybe a wild guess, but this could save Ariane V. A program assumed
>>>> Constraint_Error exception free was recompiled for the hardware where
>>>> that was not the case.)
>>> 
>>> My understanding is that the system was brought down by an unexpected
>>> hardware exception - i.E. one which the CPU's floating point unit
>>> generated.
>> 
>> Yes, and that would be detected by the compiler:
>> 
>>    function Integer (X : Float) return Integer;
>> 
>> which was contracted as exception-free on one platform will not be on
>> another. So the compiler would reject either its implementation that
>> raises Constraint_Error or else its use contracted as
>> Constraint_Error-free. So the idea.
>> 
>> (Contracted exceptions would mean a damn LOT of work for the compiler
>> vendors.)
> 
> I forgot to mention mentioned that they used pragma Suppress to speed thing
> up (the old 'pedia article mentioned that). With pragma Suppress  in place
> the HW-exception was never converted into an Ada-exception.
> 
> Even the best exception handling won't help if you switch it off :-( .

See, but you could not switch off the language! (:-))

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

Re: Exceptions

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 23:40:20 +0100, Georg Bauhaus wrote:

> Robert A Duff wrote:

>> I think there are some mistakes in the Java design for exceptions, but I
>> don't think the whole idea of exception contracts is bad.
>> 
> When Robert Dewar talked about exceptions at MIT (I think, that's
> from memory of a video recording), one of his arguments was that
> you don't want to write cascades of conditionals for handling
> return values (being either returned values or failure indicators)
> ---because that's a mess.
> 
> Now, when we have a sequence of statements in a block,
> 
>    P1(X); P2(X); ... ; Pn(X, Y);
> 
> then what will be the average number of exception handlers
> for this block? Involving how many different exceptions?

Close to 0.

1. How often do you declare a new exception when writing a new subprogram?
My guess is about 1 / 10_000.

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

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.

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

Re: Exceptions

[Dmitry A. Kazakov]

On Sun, 09 Dec 2007 11:38:46 -0500, Peter C. Chapin wrote:

> Dmitry A. Kazakov wrote:
> 
>> Then I would propose:
>> 
>> begin
>>    P1 (X);
>> exception
>>    when Empty_String_Error =>
>>        -- do something else
>> end;
> 
> I only want X to contain a name from the database. I have to check for
> that someplace regardless of what P1 wants to do. Checking for it inside
> P1 doesn't work because P1 is a general purpose string handling
> algorithm that knows nothing about my application.

Then I didn't understand the example. If P1 does not check X why should it
raise any exception?

>> Isn't this indeed a waste of resources? Validation is performed twice, once
>> in Has_Acceptable_Value and once in P1!
> 
> In this example P1 doesn't validate. It just assumes the document is
> valid and skips as much error handling as possible. However P1, or
> subprograms it calls, might have the potential of raising a variety of
> exceptions, including perhaps C_E if P1 is inadvertently given an
> invalid document.

In that case you just cannot say that P1 does not propagate
Constraint_Error, because it is too difficult to spell the conditions of
propagation. You put all trust in some Validate (X), which is designed
independently on P1. How can you be certain that Validate indeed prevents
Constraint_Error in P1?  I would never do, so a handler for
Constraint_Error looks quite appropriate to me.

> In XML based applications I've written, I validate the document once and
> then let the rest of the program just assume it is valid.

OK, I would parse once, but that is another story. My point is that handler
were a good idea because Validate and P1 are decoupled.

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

Re: Exceptions

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

>>
>> Now, when we have a sequence of statements in a block,
>>
>>    P1(X); P2(X); ... ; Pn(X, Y);
>>
>> then what will be the average number of exception handlers
>> for this block? Involving how many different exceptions?
> 
> Close to 0.
> 
> 1. How often do you declare a new exception when writing a new subprogram?
> My guess is about 1 / 10_000.

OK, assume programmers will declare new exceptions only for
1 / 10_000 subprograms.

   procedure P1(X: Temperature) raise Constraint_Error;
   procedure P5(X: Pressure) raise Constraint_Error;

begin
   P1(Hot); P5(Deflated);
exception
   when Constraint_Error =>
       ?
end;

Do programmers put a block around every procedure call so
that the proper occurence of Constraint_Error is handled?
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?

> There is not that many handlers in a good designed code.

Hear, hear. [Q] Why do we need more exception announcements, then?
Will design improve because of subp with exception announcements?

> 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_?
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).

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? :-)

Re: Exceptions

[Georg Bauhaus]

Georg Bauhaus wrote:

>   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
I forgot the important part: the "comment" keyword will have
the desired effect of uncovering information to the team.

Re: Exceptions

[Dmitry A. Kazakov]

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

Re: Exceptions

[Niklas Holsti]

Dmitry A. Kazakov wrote:

 > [some questions, see below]

I'm not sure if Dmitry really wants answers to his questions below 
-- perhaps they were merely rhetorical -- but they tickled my 
curiosity, so here is one data point from my main Ada application:

Number of packages (.ads files)                   :     196
Number of package bodies (.adb files)             :     147
Total source lines (including blanks and comments): 201_731
Total number of lines with semicolons             :  42_935
Total number of subprograms                       :   6_292

Exceptions declared                               :      87

Explicit raise statements (with exception name)   :     239
- of Constraint_Error (note 1)                    :      20
- of Program_Error    (note 1)                    :      12
- of application-defined exceptions               :     207

Exception-handler sequences (note 2)              :     219
Exception handlers (note 3)                       :     275

Handlers that "eat "exceptions (note 4)           :     180
- eat specific application-defined exception(s)   :     129
- eat specific language-defined exception(s)      :      34
- eat "others"                                    :      17

Handlers that raise or re-raise exceptions        :     102
- propagate same application-defined exception    :      13
- propagate same language-defined exception       :      22
- propagate same "others" exception               :      28
- change app-def. exc. to other app-def. exc.     :      20
- change language-def. exc. to app-def. exc.      :      18
- change app-def. exc. to language-def. exc.      :       1


Notes:
   1. Of the language-defined exceptions, only
      Constraint_Error and Program_Error are raised
      explicitly (by "raise <name>").
   2. An "exception-handler sequence" is the list of
      exception_handlers at the end of a handled_-
      sequence_of_statements.
   3. Whether for one exception, several exceptions,
      or "others".
   4. Handlers that do not contain "raise" statements.

Some of the above was counted by hand from "grep" outputs, so the 
numbers may be off by a couple of units.

It is noteworthy that most exception-handler sequences (total: 219) 
only have one exception handler (total: 275), although this single 
handler often handles several exceptions, or "others".

> 1. How often do you declare a new exception when writing a new subprogram?
> My guess is about 1 / 10_000.

 From the numbers above: 87 / 6_292 = 138 / 10_000. In some cases 
one declared exception can be raised in several subprograms, but I 
think the average number of subprograms that can raise a given 
application-defined exception is between 1 and 2, not larger, in 
this application.

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

My numbers do not separate between exceptions propagated from calls 
and exceptions raised within the handled sequence-of-statements 
itself. But my feeling is that at least half of the handlers are 
meant to catch exception from calls, and I don't think that there 
is any systematic difference in the proportion of "eaters" versus 
"propagators" between the two cases.

So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = 
  6.5 / 10.

> There is not that many handlers in a good designed code.

That is too generalized. I think that the number of handlers is 
partly a matter of personal style (preference for error-code 
parameters vs exceptions) and partly depends on the required level 
of error tolerance (ability to continue processing in spite of 
errors). Good error tolerance may require more local handlers to 
clean up local state, before (possibly) passing the exception to 
higher levels.

The application behind the numbers given above is not required to 
be error-tolerant. Thus, many exceptions can simply be propagated 
to a high level, without passing through many local clean-up 
handlers on the way.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Exceptions

[Dmitry A. Kazakov]

On Mon, 10 Dec 2007 14:09:31 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
> 
>  > [some questions, see below]
> 
> I'm not sure if Dmitry really wants answers to his questions below 
> -- perhaps they were merely rhetorical -- but they tickled my 
> curiosity, so here is one data point from my main Ada application:

Thank you for the figures. It is really interesting.

>> 1. How often do you declare a new exception when writing a new subprogram?
>> My guess is about 1 / 10_000.
> 
>  From the numbers above: 87 / 6_292 = 138 / 10_000.

One per hundred also. As for me I tend to reuse IO_Exceptions if semantics
is close, so my figure should be much lesser.

> In some cases 
> one declared exception can be raised in several subprograms, but I 
> think the average number of subprograms that can raise a given 
> application-defined exception is between 1 and 2, not larger, in 
> this application.

This is a very low figure. But as I said, I reuse exceptions much. A
possible danger is to overload an exception too much (like Constraint_Error
already is).

This is IMO a question of custom and also of the language design. When
exceptions tend to propagate out of the application, one would certainly
like to make them "meaningful" indicating the fault reason as precise as
possible. This is not what I wanted from Ada. I'd like to have all
exceptions handled. So I treat them rather as signals within and for the
application. I don't buy exceptions as a debugging tool.

>> 2. How often does a caller "eat" an exception of the callee instead of
>> propagating it further? My guess is 1 / 10.
> 
> My numbers do not separate between exceptions propagated from calls 
> and exceptions raised within the handled sequence-of-statements 
> itself. But my feeling is that at least half of the handlers are 
> meant to catch exception from calls, and I don't think that there 
> is any systematic difference in the proportion of "eaters" versus 
> "propagators" between the two cases.
> 
> So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = 
>   6.5 / 10.

Interesting. I didn't measured my code, but I expect more scopes where
exceptions propagate unhandled. That depends on how much refactoring is
done. Actually, I have an impression that many exception-related bugs
appear while code refactoring and other small apparently equivalent code
modifications, which in turn are not almost equivalent.

>> There is not that many handlers in a good designed code.
> 
> That is too generalized. I think that the number of handlers is 
> partly a matter of personal style (preference for error-code 
> parameters vs exceptions) and partly depends on the required level 
> of error tolerance (ability to continue processing in spite of 
> errors).

Yes

> Good error tolerance may require more local handlers to 
> clean up local state, before (possibly) passing the exception to 
> higher levels.

Possibly, however there is a concurring mechanism for clean-ups, I mean
controlled types. In many cases Finalize does what otherwise a handler
would.

> The application behind the numbers given above is not required to 
> be error-tolerant. Thus, many exceptions can simply be propagated 
> to a high level, without passing through many local clean-up 
> handlers on the way.

Yes, but again it is probably not about being error-[in]tolerant. I think
the overall code structure plays a role here. When I refactor small
subprogram doing this or that thing, I often leave exception handling
functionality to another piece of code. Maybe this is my personal
motivation behind longing for contracted exceptions.

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

Re: Contracted exceptions for Ada

[Robert A Duff]

Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

>> no need for a handler.  Unfortunately, there's no Non_Zero subtype.
>
> I am afraid, a non-zero subtype would move the problem around, rather
> than solve it. The exception not raised by X/Y might then be raised
> before, when you compute Y:=A-B.
>
> On a second look, this might actually be useful better diagnostics. The
> exception is raised closer to the point where the faulty value (the zero
> Y) is created, rather than, perhaps, much later.

Exactly.  Pushing the check to the caller makes it more likely that you
can prove it's true statically.

E.g. suppose you read a number from the keyboard, and pass it around,
store it in a data structure, retrieve it from the data structure, and
then divide by it.  The "read" part should do input validation, or else
there's a bug.  If all the subtypes of those parameters and data
structures had a "cannot equal zero" invariant, then the bug is isolated
to the "read" part.  And if that part says "if Value /= 0 ..." then
it's easy to prove that the bug is not there.

- Bob

Re: Exceptions

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Mon, 10 Dec 2007 14:09:31 +0200, Niklas Holsti wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
>>
>> > [some questions, see below]
>>
>>I'm not sure if Dmitry really wants answers to his questions below 
>>-- perhaps they were merely rhetorical -- but they tickled my 
>>curiosity, so here is one data point from my main Ada application:
> 
> 
> Thank you for the figures. It is really interesting.
> 
> 
>>>1. How often do you declare a new exception when writing a new subprogram?
>>>My guess is about 1 / 10_000.
>>
>> From the numbers above: 87 / 6_292 = 138 / 10_000.
> 
> 
> One per hundred also. As for me I tend to reuse IO_Exceptions if semantics
> is close, so my figure should be much lesser.

The only language-defined exceptions that are thusly "reused" in 
this application are Constraint_Error (mainly used in container 
structures that have some notion of "indexing" or "keyed look-up" 
where C_E is used to report an invalid index or key) and 
Program_Error (to kill the application when its state is screwed up 
in a way that indicates a programming error rather than an input 
error or user error).

One reason for the large number of application-defined exceptions 
in this application may be that it uses a lot of functional-style 
programming with functions that return objects with run-time 
constraints (eg. unconstrained array types). Such functions cannot 
easily use error codes and must use exceptions to signal problems.

>>In some cases 
>>one declared exception can be raised in several subprograms, but I 
>>think the average number of subprograms that can raise a given 
>>application-defined exception is between 1 and 2, not larger, in 
>>this application.
> 
> This is a very low figure.

It is my estimate for the *average* number of subprograms that 
contain raise statements for a given application-defined exception. 
There are certainly *some* exceptions that are raised in 5..10 
subprograms.

The number of subprograms that can *propagate* a given 
application-defined exception (from their callees) is larger, but I 
can't say by how much. Clearly most subprograms have no exception 
handlers at all and thus propagate all exceptions raised in them or 
in their callees.

> But as I said, I reuse exceptions much. A
> possible danger is to overload an exception too much (like Constraint_Error
> already is).

Agreed. Whenever this application explicitly raises 
Constraint_Error it is (or should be) handled a few (1 .. 3) levels 
higher in the call path. Several handlers for Constraint_Error 
(whether raised explicitly or by standard run-time checks) 
"translate" C_E to a more specific exception by raising the 
specific application-defined exception for handling at higher levels.

> This is IMO a question of custom and also of the language design. When
> exceptions tend to propagate out of the application, one would certainly
> like to make them "meaningful" indicating the fault reason as precise as
> possible.

Yes, but whatever one does, an exception occurrence is almost never 
meaningful for the user, only for the developer.

> This is not what I wanted from Ada. I'd like to have all
> exceptions handled. So I treat them rather as signals within and for the
> application.

If I can foresee a situation that can cause a certain exception, of 
course I put in a handler. The problem is programming errors or 
input errors that I do not foresee. For such I still rely on 
catch-all handlers at certain levels and ask the user to send me 
the error messages that these handlers emit.

> I don't buy exceptions as a debugging tool.

Exceptions (even when unhandled) are an essential part of my 
debugging kit, but of course not the only part. In the application 
under discussion an unhandled (or "others" handled) exception 
typically only indicates the presence of a programming error, not 
its location or its nature. For the rest, I tend to use programmed 
internal checks and action/state traces that can be turned on with 
specific command-line options. I rarely use a real debugger.

>>>2. How often does a caller "eat" an exception of the callee instead of
>>>propagating it further? My guess is 1 / 10.
>>
>>My numbers do not separate between exceptions propagated from calls 
>>and exceptions raised within the handled sequence-of-statements 
>>itself. But my feeling is that at least half of the handlers are 
>>meant to catch exception from calls, and I don't think that there 
>>is any systematic difference in the proportion of "eaters" versus 
>>"propagators" between the two cases.
>>
>>So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = 
>>  6.5 / 10.
> 
> 
> Interesting. I didn't measured my code, but I expect more scopes where
> exceptions propagate unhandled.

Sure, I was just comparing *handlers* that "eat" versus handlers 
that "propagate". Most subprograms have no handlers and propagate 
all exceptions.

In another post, you (Dmitry) say that your question (2) meant the 
number of call levels over which an exception usually propagates 
before being handled -- the "distance" between the raise point and 
the handler. I haven't measured that for my application, but my 
feeling is that there are two kinds of exception (occurrences): the 
non-fatal ones and the fatal or semi-fatal ones.

For a non-fatal exception the application takes some corrective 
action, for example throws away some small unit of data or 
increases the size of a container structure, and then continues 
processing. In this application the raise-to-handle distance for 
such exceptions is small, 1..3 levels I would say.

For a fatal or semi-fatal exception this application either stops 
completely or skips a major part of its input and continues with 
the remaining parts. Here the raise-to-handle distance is large and 
the handler is often an "others" handler.

> That depends on how much refactoring is
> done. Actually, I have an impression that many exception-related bugs
> appear while code refactoring and other small apparently equivalent code
> modifications, which in turn are not almost equivalent.

This app has had only a handful of exception-related bugs, most 
coming from null accesses, a couple from overflows (the app handles 
machine-level binary numbers of various sizes). I can't say if they 
are related to refactoring of any sort.

>>Good error tolerance may require more local handlers to 
>>clean up local state, before (possibly) passing the exception to 
>>higher levels.
> 
> Possibly, however there is a concurring mechanism for clean-ups, I mean
> controlled types. In many cases Finalize does what otherwise a handler
> would.

True. This app was started when Ada 95 was young, and we were a bit 
afraid of compiler bugs in controlled types, so almost no 
controlled types are used (Unbounded_String is used in several 
places, though).

>>The application behind the numbers given above is not required to 
>>be error-tolerant. Thus, many exceptions can simply be propagated 
>>to a high level, without passing through many local clean-up 
>>handlers on the way.

(Commenting on my own text above: these are the "fatal or 
semi-fatal" exceptions.)

> Yes, but again it is probably not about being error-[in]tolerant. I think
> the overall code structure plays a role here. When I refactor small
> subprogram doing this or that thing, I often leave exception handling
> functionality to another piece of code. Maybe this is my personal
> motivation behind longing for contracted exceptions.

The main problem I see in contracted exceptions is the problem with 
layered architectures where some intermediate layers are 
general/generic and not application-specific. For example, a 
generic tree-traversal (intermediate) layer may have to propagate 
application-defined exceptions from the application-specific 
"action" routines in a lower layer, to the application's handlers 
in a higher layer. I don't see how to do that easily with explicit 
exception contracts. It may be easier in a language with exception 
classes that can be derived into exception subclasses that have 
application-defined occurrence-specific data components. The 
intermediate layer could define its own exception class(es) for 
such propagated exceptions and the application would define 
subclass(es) with application-specific information. The contract of 
the intermediate layer could the list the exception class(es), not 
the subclass(es).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Contracted exceptions for Ada

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 09 Dec 2007 18:39:31 +0000, Simon Wright wrote:
>>     In Ariane IV the maximum horizontal velocity is X.
>> 
>>     Therefore we can convert the hardware input to this-type without
>>     worrying about overflow.
>
> Hardware input had a type different from one used later in the
> control circle, because it needed to be converted. So what was the
> contract of that conversion?

The Ariane IV system engineers said to themselves, and probably in the
design documentation, "The maximum horizontal velocity is X. Therefore
the conversion to the fixed-point type _Whatever_ cannot
overflow. Therefore we do not need to handle exceptions for this
conversion, so (given we are short of CPU power) we will not do any
extra processing to avoid exceptions."

Not sure they would have recognised "contract" in that context.

> My point is that the fault could be detected (assuming that
> conversion was in Ada), under the condition that the compiler vendor
> would not make the same mistake while porting the compiler... (:-))

Not if there was no port, and the exact same hardware with the exact
same software was reused! (I'm not sure if that was in fact the case)

Re: Contracted exceptions for Ada (was: Exceptions)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:7m9wkymyi5h7.1235e72is9mp9.dlg@40tude.net...
> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote:
...
> > The ARG has discussed "exception contracts" a couple of times, but there
> > didn't seem that there was enough interest. The problem was mainly that
they
> > simply don't look very valuable
>
> My observation is that a big deal of debugging Ada code is about tracing
> down unexpected exceptions. I cannot give any figures, but it is extremely
> frequent that a bug manifests itself as an exception propagation.
Typically
> Constraint_Error propagates where you didn't expect it. So the temptation
> is to catch most of such things at compile time.

That's not going to be useful, since virtually any code that you can write
*might* raise Constraint_Error, and a lot of code *could* raise
Program_Error, and everything *could* raise Storage_Error. There is no way
to write a contract that doesn't contain those exceptions.

...
> > Another one is what to do if a contract is violated. The obvious answer
of
> > raising Program_Error doesn't do anything other than lose information
about
> > an exception, so that isn't very satisfying.
>
> Yes, in my view exception contracts have to be static. (It makes no sense
> to have run-time exception contracts. As well as any other contracts,
there
> is no any authority body to judge contract violations at run-time.)

OK, but that isn't going to happen in Ada. What you are looking for is a
static analysis tool, like SPARK. That's especially true as you'll need
static preconditions to have any hope of eliminating the Constraint_Errors
(subtypes aren't powerful enough). It is highly unlikely that the language
is going to go in that direction; the language has been very careful to
avoid requiring analysis beyond that of a single expression, and trying to
get vendors to re-architect their compilers is probably a good way to cut
the number of Ada implementations to zero.

             Randy.

Re: Exceptions

[Randy Brukardt]

"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.

Re: Exceptions

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:194zh0rz03487$.6vxhavjdbpdr.dlg@40tude.net...
...
> 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? (:-))

Actually, this is perfectly legal because there is a value returned, and Ada
doesn't require any sort of path analysis (it is impossible in the general
case). It does raise Program_Error, but that is very different. Especially
since you are talking about static contracts...

           Randy.

Re: Exceptions

[Stephen Leake]

Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> writes:

> Robert A Duff wrote:
>
>>     when Funcs_Important_Exception =>
>>         -- <comment explaining why this can never happen>
>>         raise Program_Error;
>> Why on earth would anybody write "null;" there?!
>> 
>
> "We know that when this library routine complains,
> it doesn't concern us. Besides, why should we pester
> the customer or the user with messages and tracebacks that
> do not matter?" (In some cultures, openly announcing errors
> is not the preferred strategy  ;-)

For third party libraries that I can't fix, I agree; I have code like
that myself. Although I also strive to change the way I use the
library to avoid the bug, but sometimes that's not possible.

For code I have control over, I agree with Bob, except I use a
different exception; raise Programmer_Error if you've detected a bug.

-- 
-- Stephe

Re: Contracted exceptions for Ada

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 09 Dec 2007 05:22:44 -0500, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote:
>>>
>>>> Another one is what to do if a contract is violated. The obvious answer of
>>>> raising Program_Error doesn't do anything other than lose information about
>>>> an exception, so that isn't very satisfying.
>>>
>>> Yes, in my view exception contracts have to be static. 
>> 
>> The only way to statically enforce exception contracts is to use SPARK
>> Ada (http://www.praxis-his.com/sparkada/). SPARK Ada does do exactly
>> that (among other things); it also signficantly restricts the Ada
>> language to a manageable subset.
>
> (I doubt that limitations of SPARK are caused by contracted exceptions. 

Correct. The limitations are introduced to make static analysis
tractable with the current state of the art.

> It just does right what Ada didn't.

I wouldn't go that far. As time goes on, more of Ada is permitted in
Spark, because the static analysis technology, and the computers it
runs on, gets better.

>> So if you like exception contracts, use SPARK Ada.
>> 
>> If you like all the things SPARK Ada leaves out (I don't have the
>> current list handy; it doesn't seem to be on the web site), use
>> standard Ada.
>
> This does not answer the questions, which are two:
>
> 1. Are contracted exceptions any good?

Yes, for high integrity systems.

> 2. Can Ada have them?

No, because it is too hard to do the static analysis to enforce the contracts.

-- 
-- Stephe

Re: Exceptions

[Georg Bauhaus]

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?

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; in fact, DbC warns you that DbC is not at all about invalid
input.

>>> 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, it may damage things;
but this case seems contrued like its counterpart: that in S1; S2;,
S1 fails. This failure need not have an effect on S2!


>> 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.


 > I can only say that
> contracted exceptions are well in Ada spirit.

Recently, I've read here on c.l.ada that there is Ada
and Ada in the presence of exceptions...


>> 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).


>> 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.

Again, the construct gets its effective power from the
programmer who uses it. It does not matter that you _can_
"write Fortran in any language"; what _will_ non-theorist
programmers actually do?

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.)

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

    An_Error_Has_Occured: exception;

    type S is tagged null record;  -- parent
    Null_S: constant S;

end Subsys;

package Subsys.P is

    type T is new S with null record;

    function F(X: in out T) return T raise Argh;

end Subsys.P;

package Subsys.Q is

    type T is new S with null record;

    procedure G(X: in out T) return T raise Oops;

end Subsys.P;

with Subsys;
procedure Job raise Subsys.An_Error_Has_Occured;
   -- client


with Subsys.P, Subsys.Q;
procedure Job is
    use Subsys;
begin
    L: declare
       Result : S'class := Q.G(P.F(Null_S));  -- HERE
    begin
       -- ... actions
       null;
    end L;
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.

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

with Subsys.P, Subsys.Q;
procedure Job_Alt is
    use Subsys;
begin

    -- Split   Q.G(P.F(Null_S));  into constituent parts
    -- so that the compiler can differentiate by exception

    Handle_G_Exception: declare
       F_Result : S'class := P.F(Null_S);
    begin
       L: declare
          G_Result : S'class := Q.G(F_Result);
       begin
          -- ... actions
          null;
       end L;
    exception
       when Oops =>
          raise An_Error_Has_Occured;
    end Handle_G_Exception;

exception  -- occurence likely raised by P.F
    when Argh =>
       -- Oops (refactoring missed the name change)
       -- is o.K., our software is robust
       null;
end Job_Alt;

If this style becomes customary for the proper handling of

    Q.G(P.F(Null_S));

then I'm not sure that announcing exceptions alone is that
useful a language change.  The example given makes me assume that
the increase in SLOC count is opening doors to another row of
error candidates.

The requires/modifies/ensures model seems more practical to
me.  It doesn't force handling exceptions; still many programmers
using that model seem to be writing preconditions at least.

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Mon, 10 Dec 2007 20:25:34 +0000, Simon Wright wrote:

> The Ariane IV system engineers said to themselves, and probably in the
> design documentation, "The maximum horizontal velocity is X. Therefore
> the conversion to the fixed-point type _Whatever_ cannot
> overflow. Therefore we do not need to handle exceptions for this
> conversion, so (given we are short of CPU power) we will not do any
> extra processing to avoid exceptions."
>
> Not sure they would have recognised "contract" in that context.

Yes, my premise was that the type of H_Input changed from Ariane IV to
Ariane V. In this case translation of the conversion function
H_Input_To_Whatever could refute the second "therefore" because X would not
be the maximal possible value of H_Input anymore.

>> My point is that the fault could be detected (assuming that
>> conversion was in Ada), under the condition that the compiler vendor
>> would not make the same mistake while porting the compiler... (:-))
> 
> Not if there was no port, and the exact same hardware with the exact
> same software was reused! (I'm not sure if that was in fact the case)

You mean that the ADC was reused as well? In that case (just speculating of
course) the compiler could detect the problem already for Ariane IV,
noticing that the range of H_Input is not bound by X and forcing to add an
exception handler somewhere.

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

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Mon, 10 Dec 2007 19:53:27 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:7m9wkymyi5h7.1235e72is9mp9.dlg@40tude.net...
>> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote:
> ...
>>> The ARG has discussed "exception contracts" a couple of times, but there
>>> didn't seem that there was enough interest. The problem was mainly that they
>>> simply don't look very valuable
>>
>> My observation is that a big deal of debugging Ada code is about tracing
>> down unexpected exceptions. I cannot give any figures, but it is extremely
>> frequent that a bug manifests itself as an exception propagation. Typically
>> Constraint_Error propagates where you didn't expect it. So the temptation
>> is to catch most of such things at compile time.
> 
> That's not going to be useful, since virtually any code that you can write
> *might* raise Constraint_Error,

Why is it a problem?

> and a lot of code *could* raise
> Program_Error, and everything *could* raise Storage_Error. There is no way
> to write a contract that doesn't contain those exceptions.

Program_Error is not my concern. Storage_Error can be fixed as I described
earlier.

And for all, what I meant under exception contracts was not about making a
program exception-free. It was about specifying which exception can
propagate and which cannot.

>>> Another one is what to do if a contract is violated. The obvious answer of
>>> raising Program_Error doesn't do anything other than lose information about
>>> an exception, so that isn't very satisfying.
>>
>> Yes, in my view exception contracts have to be static. (It makes no sense
>> to have run-time exception contracts. As well as any other contracts, there
>> is no any authority body to judge contract violations at run-time.)
> 
> OK, but that isn't going to happen in Ada. What you are looking for is a
> static analysis tool, like SPARK. That's especially true as you'll need
> static preconditions to have any hope of eliminating the Constraint_Errors
> (subtypes aren't powerful enough).

This is a separate issue. You seem to imply that the exception contracts
shall specify *when* an exception is raised or not. That is a much harder
problem and it indeed would require pre- and postconditions and cannot be
done in general case. What I am talking about is a much weaker framework
which only proves whether an exception cannot propagate. We do not need
pre-/postconditions for that.

A comparable case is exact real vs. interval arithmetic. We don't need
exact exception propagation analysis, we do a conservative *estimation* of.

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

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Tue, 11 Dec 2007 03:10:36 -0500, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> 2. Can Ada have them?
> 
> No, because it is too hard to do the static analysis to enforce the contracts.

It is a misunderstanding, I addressed this question in my answer to Randy.

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

Re: Exceptions

[Dmitry A. Kazakov]

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

Re: Exceptions

[Dmitry A. Kazakov]

On Mon, 10 Dec 2007 22:02:55 +0200, Niklas Holsti wrote:

> One reason for the large number of application-defined exceptions 
> in this application may be that it uses a lot of functional-style 
> programming with functions that return objects with run-time 
> constraints (eg. unconstrained array types). Such functions cannot 
> easily use error codes and must use exceptions to signal problems.

I tend use End_Error, Use_Error, Data_Error in such cases. The question is
how many different exceptions may propagate from a set of closures used in
one context. Not that many, so my guess is that one need not so many
different exceptions.

> Clearly most subprograms have no exception 
> handlers at all and thus propagate all exceptions raised in them or 
> in their callees.

Yes, this why I don't believe in the argument of abundant exception
handlers spoiling each and other program block. I don't see why contracts
should change anything here.
 
>> This is IMO a question of custom and also of the language design. When
>> exceptions tend to propagate out of the application, one would certainly
>> like to make them "meaningful" indicating the fault reason as precise as
>> possible.
> 
> Yes, but whatever one does, an exception occurrence is almost never 
> meaningful for the user, only for the developer.

Right.

>> This is not what I wanted from Ada. I'd like to have all
>> exceptions handled. So I treat them rather as signals within and for the
>> application.
> 
> If I can foresee a situation that can cause a certain exception, of 
> course I put in a handler. The problem is programming errors or 
> input errors that I do not foresee. For such I still rely on 
> catch-all handlers at certain levels and ask the user to send me 
> the error messages that these handlers emit.

Which is one of the advantages of the contracted model.

A typical scenario: A lazy (let's say busy) programmer designs some set of
low-level primitives raising some exceptions. Then he starts to write a
middle layer that reuses those primitives, not necessarily in exactly this
order, but anyway. The exceptions of the middle layer are different, and of
course, the lower level exceptions do not propagate out the middle layer.
At this point he has already forgot most of when and what the lower level
raises. He remembers the exceptions E3 and E10, but the rest is vanished.
He decides whether to use "when others" but has no clear idea what to do
there, so maybe he places something looking more or less appropriate there
hoping that the debugging phase will shed more light on the issue, or just
drop it, depending on how much coffee he already had. The rest is obvious.
Does it sound familiar?

Now a contracted exceptions scenario: The programmer contracts a
middle-layer subprogram as non-propagating anything he does not want to. He
does not write any handlers, just compiles the code. The compiler complains
about E1. Aha - he says, where that E1 comes from? This repeats until all
low-level exceptions are caught, *understood* and handled.

> The main problem I see in contracted exceptions is the problem with 
> layered architectures where some intermediate layers are 
> general/generic and not application-specific. For example, a 
> generic tree-traversal (intermediate) layer may have to propagate 
> application-defined exceptions from the application-specific 
> "action" routines in a lower layer, to the application's handlers 
> in a higher layer. I don't see how to do that easily with explicit 
> exception contracts. It may be easier in a language with exception 
> classes that can be derived into exception subclasses that have 
> application-defined occurrence-specific data components. The 
> intermediate layer could define its own exception class(es) for 
> such propagated exceptions and the application would define 
> subclass(es) with application-specific information. The contract of 
> the intermediate layer could the list the exception class(es), not 
> the subclass(es).

I think there is no simple answer to this. What could help IMO is:

1. Conditional exception contracts (for things like Storage_Error and
exceptions from the closures)

2. Inheritable exception contracts (to be able to refer to a group of
exceptions from another subprogram)

3. Making exceptions an ordered type with some kind of tree-like distance.

4. Renaming/delegation of exceptions.

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

Re: Exceptions

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Mon, 10 Dec 2007 22:02:55 +0200, Niklas Holsti wrote:
> 
>>One reason for the large number of application-defined exceptions 
>>in this application may be that it uses a lot of functional-style 
>>programming with functions that return objects with run-time 
>>constraints (eg. unconstrained array types). Such functions cannot 
>>easily use error codes and must use exceptions to signal problems.
> 
> I tend use End_Error, Use_Error, Data_Error in such cases.

I don't like that at all, because in my mind End_Error etc. are 
associated with Ada IO, not with my application -- their meaning 
(semantics :-) is not appropriate, and I don't want to be Humpty 
Dumpty and make them mean what I want them to mean.

Of course, if the function in question actually is reading a file, 
and fails because the file ends at an unexpected point, then 
End_Error could be appropriate. But for a function that has no 
connection with IO I would never "reuse" End_Error just to avoid 
declaring a specific exception.

> The question is
> how many different exceptions may propagate from a set of closures used in
> one context. Not that many, so my guess is that one need not so many
> different exceptions.

But surely one of the main points of a contract is to show what a 
caller may have to do, to handle the propagated exceptions. To 
"overload" one exception (such as End_Error) with many different 
meanings, perhaps requiring different handling, would make the 
caller's job difficult.

I agree that the number of different exceptions that are usefully 
propagated from most subprograms is generally small, because the 
caller does not have enough understanding of the possible 
exceptional situtations in the callee to be able to handle many 
different exceptions in specific ways.

>>Clearly most subprograms have no exception 
>>handlers at all and thus propagate all exceptions raised in them or 
>>in their callees.
> 
> Yes, this why I don't believe in the argument of abundant exception
> handlers spoiling each and other program block. I don't see why contracts
> should change anything here.

I think all subprograms would need contracts (to specify the 
possibly propagated exceptions), not just the few subprograms that 
have exception handlers. The contract has to be in the subprogram 
declaration, while the presence or absence of exception handlers is 
a property of the body.

Exception contracts could become a considerable part of the source 
code, especially if they would have to include the "always 
possible" exceptions like Storage_Error and in the absence of any 
SPARK-like analysis to exclude impossible exceptions from the contract.

> A typical scenario: A lazy (let's say busy) programmer designs some set of
> low-level primitives raising some exceptions. Then he starts to write a
> middle layer that reuses those primitives, not necessarily in exactly this
> order, but anyway. The exceptions of the middle layer are different, and of
> course, the lower level exceptions do not propagate out the middle layer.
> At this point he has already forgot most of when and what the lower level
> raises. He remembers the exceptions E3 and E10, but the rest is vanished.
> He decides whether to use "when others" but has no clear idea what to do
> there, so maybe he places something looking more or less appropriate there
> hoping that the debugging phase will shed more light on the issue, or just
> drop it, depending on how much coffee he already had. The rest is obvious.
> Does it sound familiar?

Not really. I use informal exception contracts (in comments 
describing each and every subprogram), so I have not experienced 
that kind of mess. But I have mistakenly omitted a necessary 
handler once or twice, generally when the raise-to-handle distance 
has been very large (fatal or semi-fatal exception).

> Now a contracted exceptions scenario: The programmer contracts a
> middle-layer subprogram as non-propagating anything he does not want to. He
> does not write any handlers, just compiles the code. The compiler complains
> about E1. Aha - he says, where that E1 comes from? This repeats until all
> low-level exceptions are caught, *understood* and handled.

That would be ideal, and very much in the Ada spirit. But I can see 
why it is not an easy addition to Ada.

>>The main problem I see in contracted exceptions is the problem with 
>>layered architectures where some intermediate layers are 
>>general/generic and not application-specific....
> 
> I think there is no simple answer to this. What could help IMO is:
> 
> 1. Conditional exception contracts (for things like Storage_Error and
> exceptions from the closures)
> 
> 2. Inheritable exception contracts (to be able to refer to a group of
> exceptions from another subprogram)
> 
> 3. Making exceptions an ordered type with some kind of tree-like distance.
> 
> 4. Renaming/delegation of exceptions.

And perhaps also

   5. Exceptions as formal generic parameters.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Exceptions

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> 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. ...

This 1/10 number seems to be a guess at some sort of average (as in
"mean").  I think it's misleading for the same reason it's misleading to
say "The average income in so-and-so town is $1,000,000 per year".  It
might mean everybody's well off, or it might mean there's one super-rich
guy, and everybody else in that town is starving.

I think there are two kinds of exceptions: one that is handled
approximately 1 level up the call chain, and the other that is handled
way far up the call chain (near the main program, or not at all
-- "not at all" = "by the Ada RTS").

The former kind is the one that might benefit from exception contracts.
For the latter kind, one would use unchecked exceptions.  Thus there
is never a case where you are "forced" to mention the same exception
all the way up 10 levels.

Note that if you have a checked exception, and it really should be an
unchecked one for some particular client, that client can turn it into
an unchecked exception at that level, with no need to mention it
in the next 9 levels.

- Bob

Re: Exceptions

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

> 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.

OK, I beg to differ. Exceptions (starting with their very name)
should not be (mis)used for signalling information IMHO. Ada has
better tools for sending messages, or for information passing.


>> 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?

The exceptions have been switched so handling must make
a corresponding switch, but there is no way to notice this at
the client side (F(G(X)). Which was the point.

Re: Exceptions

[Simon Wright]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> For code I have control over, I agree with Bob, except I use a
> different exception; raise Programmer_Error if you've detected a
> bug.

neat!

Re: Contracted exceptions for Ada

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 10 Dec 2007 20:25:34 +0000, Simon Wright wrote:
>
>> The Ariane IV system engineers said to themselves, and probably in
>> the design documentation, "The maximum horizontal velocity is
>> X. Therefore the conversion to the fixed-point type _Whatever_
>> cannot overflow. Therefore we do not need to handle exceptions for
>> this conversion, so (given we are short of CPU power) we will not
>> do any extra processing to avoid exceptions."
>>
>> Not sure they would have recognised "contract" in that context.
>
> Yes, my premise was that the type of H_Input changed from Ariane IV
> to Ariane V. In this case translation of the conversion function
> H_Input_To_Whatever could refute the second "therefore" because X
> would not be the maximal possible value of H_Input anymore.

X was *never* the maximum possible value of H_Input!

Re: Exceptions

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:475e8bde$0$27850$4f793bc4@news.tdc.fi...
...
> And perhaps also
>
>    5. Exceptions as formal generic parameters.

Ada has this (although it isn't obvious): just pass an
Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec
something like:

    generic
         My_Exception : Ada.Exceptions.Exception_Id :=
Constraint_Error'Identity;
    package Gen is ...

you can instantiate it with any exception you like:

     package Inst is new Gen (Program_Error'Identity);

and you can raise the exception inside the generic:

     Ada.Exceptions.Raise_Exception (My_Exception, Message => "Wow!");

and you can even handle the exception with a little cleverness:

    when Occ:others =>
           if Ada.Exceptions.Exception_Identity (Occ) = My_Exception then
                -- Handle My_Exception.
           else
                 raise; -- Not the one we want.
           end if;

(This last is how Janus/Ada has to implement handlers for exceptions
declared inside of generics anyway, so in our case at least, the code cost
is essentially the same.)

All but the last as just as good as a "real" exception formal, and the last
doesn't happen that much in reusable stuff (usually such things are
originating or propagating exceptions, not handling them).

In any case, the fact that it is relatively easy to do this is why there is
no formal exception parameter.

                           Randy.

Re: Exceptions

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccr6ht5ki4.fsf@shell01.TheWorld.com...
...
> This 1/10 number seems to be a guess at some sort of average (as in
> "mean").  I think it's misleading for the same reason it's misleading to
> say "The average income in so-and-so town is $1,000,000 per year".  It
> might mean everybody's well off, or it might mean there's one super-rich
> guy, and everybody else in that town is starving.
>
> I think there are two kinds of exceptions: one that is handled
> approximately 1 level up the call chain, and the other that is handled
> way far up the call chain (near the main program, or not at all
> -- "not at all" = "by the Ada RTS").
>
> The former kind is the one that might benefit from exception contracts.
> For the latter kind, one would use unchecked exceptions.  Thus there
> is never a case where you are "forced" to mention the same exception
> all the way up 10 levels.
>
> Note that if you have a checked exception, and it really should be an
> unchecked one for some particular client, that client can turn it into
> an unchecked exception at that level, with no need to mention it
> in the next 9 levels.

I don't buy the supposed need for two kinds of exceptions. It seems to me to
be an implicit recognition of the fact that the contracts aren't
sufficiently useful for many kinds of subprograms. I think it would be
better to fix the capability of the contracts (if that's possible) than to
define a trivial way to avoid them.

Once you have unchecked exceptions, the contract really doesn't tell you
anything interesting (since it is the propagation of predefined exceptions
that usually lead to bugs; only the rare case where the predefined exception
is caught will tell you anything at all). Moreover, the temptation is
overwhelming to use the unchecked kind everywhere, because it is less hassle
and the checked kind doesn't buy that much anyway (it doesn't guarentee that
all exceptions are handled, but only the rare few that are declared
checked).

It's much like the accessibility rules in Ada. They're immensely
complicated, yet their original primary goal is completely ignored. I've
never yet found an Ada program where I could use 'Access on an object; I
don't even bother trying anymore. So why have all of that complication?
(Yes, I know its useful for subprograms and tagged types, and we can't avoid
it there.)

                                  Randy.


I vie

Re: Contracted exceptions for Ada

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:185k0c8e598ko.16o5j2iv35zpn$.dlg@40tude.net...
> On Mon, 10 Dec 2007 19:53:27 -0600, Randy Brukardt wrote:
...
> > That's not going to be useful, since virtually any code that you can
write
> > *might* raise Constraint_Error,
>
> Why is it a problem?

Because every contract would have to include Constraint_Error, and that
would add a huge amount of verbiage to programs for no benefit. Or you have
to exclude it from the contract like Java does, which would be worse.

> > and a lot of code *could* raise
> > Program_Error, and everything *could* raise Storage_Error. There is no
way
> > to write a contract that doesn't contain those exceptions.
>
> Program_Error is not my concern. Storage_Error can be fixed as I described
> earlier.

Program_Error *is* your concern. There is no way that a compiler could prove
that it would not be raised from a lot of code; as such it would have to be
included in the contract even though it isn't interesting to anyone
(presuming again static contract checking and no "unchecked" exceptions).

And your solution for Storage_Error adds a large number of new rules to the
language, and is unlikely to make it possible to eliminate the exception.
For instance, other tasks can allocate memory for the heap, so the only
possible way to tell if you are out of heap memory is to catch the
exception -- anything else is a race. And Janus/Ada at least uses heap
memory to allocate virtually everything not statically sized: pretty much
anything other than an elementary object or "null;" can raise Storage_Error
in Janus/Ada. Besides, you say you don't want to add preconditions and the
like, and then you do exactly that to handle Storage_Error. Can't have it
both ways...

> And for all, what I meant under exception contracts was not about making a
> program exception-free. It was about specifying which exception can
> propagate and which cannot.

Right, but the predefined exceptions can always propagate. The only way to
prove that they don't is to do extensive static analysis, and that isn't
happening in the language.

> >>> Another one is what to do if a contract is violated. The obvious
answer of
> >>> raising Program_Error doesn't do anything other than lose information
about
> >>> an exception, so that isn't very satisfying.
> >>
> >> Yes, in my view exception contracts have to be static. (It makes no
sense
> >> to have run-time exception contracts. As well as any other contracts,
there
> >> is no any authority body to judge contract violations at run-time.)
> >
> > OK, but that isn't going to happen in Ada. What you are looking for is a
> > static analysis tool, like SPARK. That's especially true as you'll need
> > static preconditions to have any hope of eliminating the
Constraint_Errors
> > (subtypes aren't powerful enough).
>
> This is a separate issue. You seem to imply that the exception contracts
> shall specify *when* an exception is raised or not. That is a much harder
> problem and it indeed would require pre- and postconditions and cannot be
> done in general case. What I am talking about is a much weaker framework
> which only proves whether an exception cannot propagate. We do not need
> pre-/postconditions for that.
>
> A comparable case is exact real vs. interval arithmetic. We don't need
> exact exception propagation analysis, we do a conservative *estimation*
of.

Right, but a the only possible conservative estimate is that all code can
propagate Program_Error, Constraint_Error, and Storage_Error. Even
    exception
           when others => null;

can raise Storage_Error and Program_Error (from finalization). And if you
replace "null" with a subprogram call, you will probably introduce
Constraint_Error. Unless you do quite a bit of static analysis, you can't
prove *anything* useful about what exceptions can propagate.

Java solves this by excluding the predefined exceptions, but all that does
is makes the contracts useless -- you don't really know what might
propagate. I hardly ever have problems with user-defined exceptions like
Windows_Error or Not_Valid_Error (from Claw, as an example) propagating: the
"comment" contracts make it pretty clear what can happen, and expected
errors are quickly handled.

Without some sort of static analysis required, all access dereferences *can*
raise Constraint_Error, all integer assignments can raise Constraint_Error,
and so on. Since we want all Ada compilers to work the same (so code is
portable), you would have to define what exact rules you are allowed to use
for determining whether an exception is raised, and which ones you are not.
That is a significant effort, and is going to be hard for some compilers to
implement -- moreover, compilers that know more would have to be prohibited
from using it. None of that seems good.

                                         Randy.

Re: Contracted exceptions for Ada

[Dmitry A. Kazakov]

On Tue, 11 Dec 2007 20:50:07 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 10 Dec 2007 20:25:34 +0000, Simon Wright wrote:
>>
>>> The Ariane IV system engineers said to themselves, and probably in
>>> the design documentation, "The maximum horizontal velocity is
>>> X. Therefore the conversion to the fixed-point type _Whatever_
>>> cannot overflow. Therefore we do not need to handle exceptions for
>>> this conversion, so (given we are short of CPU power) we will not
>>> do any extra processing to avoid exceptions."
>>>
>>> Not sure they would have recognised "contract" in that context.
>>
>> Yes, my premise was that the type of H_Input changed from Ariane IV
>> to Ariane V. In this case translation of the conversion function
>> H_Input_To_Whatever could refute the second "therefore" because X
>> would not be the maximal possible value of H_Input anymore.
> 
> X was *never* the maximum possible value of H_Input!

In that case with contracted exceptions, the code without an exception
handler were illegal from the beginning.

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

Re: Exceptions

[Dmitry A. Kazakov]

On Tue, 11 Dec 2007 15:21:57 +0200, Niklas Holsti wrote:

> Exception contracts could become a considerable part of the source 
> code, especially if they would have to include the "always 
> possible" exceptions like Storage_Error and in the absence of any 
> SPARK-like analysis to exclude impossible exceptions from the contract.

Unluckily, but for backward compatibility an missing contract should be
treated as "raises exception'Class," i.e. anything. This is a problem with
most of new things recently introduced in Ada, that the defaults are more
verbose than their less safe counterparts. For example "abstract",
"interface", "overriding".

>> A typical scenario: A lazy (let's say busy) programmer designs some set of
>> low-level primitives raising some exceptions. Then he starts to write a
>> middle layer that reuses those primitives, not necessarily in exactly this
>> order, but anyway. The exceptions of the middle layer are different, and of
>> course, the lower level exceptions do not propagate out the middle layer.
>> At this point he has already forgot most of when and what the lower level
>> raises. He remembers the exceptions E3 and E10, but the rest is vanished.
>> He decides whether to use "when others" but has no clear idea what to do
>> there, so maybe he places something looking more or less appropriate there
>> hoping that the debugging phase will shed more light on the issue, or just
>> drop it, depending on how much coffee he already had. The rest is obvious.
>> Does it sound familiar?
> 
> Not really. I use informal exception contracts (in comments 
> describing each and every subprogram),

I do it as well.

> so I have not experienced 
> that kind of mess. But I have mistakenly omitted a necessary 
> handler once or twice, generally when the raise-to-handle distance 
> has been very large (fatal or semi-fatal exception).

The problem is that you have to analyse the descriptions of all m
subprograms you call in the given scope. Remember also the figure n of the
scopes where an exception propagates without handling. That gives us m x n
(width x depth) of the search as the number of things to keep in the weary
head at once. It is tedious and error prone, especially when the code gets
changed.

>> Now a contracted exceptions scenario: The programmer contracts a
>> middle-layer subprogram as non-propagating anything he does not want to. He
>> does not write any handlers, just compiles the code. The compiler complains
>> about E1. Aha - he says, where that E1 comes from? This repeats until all
>> low-level exceptions are caught, *understood* and handled.
> 
> That would be ideal, and very much in the Ada spirit. But I can see 
> why it is not an easy addition to Ada.

It would be difficult to compiler vendors, because they will have to add
exception contracts to all language constructs and library subprograms and
then maintain them upon porting the compiler to another target.

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

Re: Exceptions

[Dmitry A. Kazakov]

On Tue, 11 Dec 2007 17:13:28 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>> 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.
> 
> OK, I beg to differ. Exceptions (starting with their very name)
> should not be (mis)used for signalling information IMHO. Ada has
> better tools for sending messages, or for information passing.

This is wrong in many aspects:

A. Exceptions are more about flow control than passing data. Message
sending would an inappropriate abstraction here, for many reasons.

B. An exception signals the program state change. The name of means that
the new state is somewhat exceptional, in the sense that it is not desired,
not so common. But it is still a legal state. Bug is *no* state.

C. Exceptions as a programming language construct, per definition, are for
programming (software design). Debugging is not programming. (I hope you
aren't going to propose a "bug-driven software design paradigm" (:-))

>>> 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?
> 
> The exceptions have been switched so handling must make
> a corresponding switch,

If you want to deal with program correctness (semantics) then there should
be other tools, like SPARK.

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

Re: Exceptions

[Niklas Holsti]

Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:475e8bde$0$27850$4f793bc4@news.tdc.fi...
> ...
> 
>>And perhaps also
>>
>>   5. Exceptions as formal generic parameters.
> 
> 
> Ada has this (although it isn't obvious): just pass an
> Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec
> something like:
> 
>     generic
>          My_Exception : Ada.Exceptions.Exception_Id :=
> Constraint_Error'Identity;
>     package Gen is ...

Ha, a good technique to know, thanks.

> In any case, the fact that it is relatively easy to do this is why there is
> no formal exception parameter.

If the implementation with Exception_Id is so easy, I wonder that 
the syntax with "exception" as formal parameter is not included in 
the language. But I know that language extensions are prioritized, 
and in fact I have never needed a formal exception parameter, 
although I have sometimes written wrappers for instances of 
generics just to translate an exception defined and raised by the 
generic into some other exception for the user of the generic.

In any plan to extend Ada with exception contracts, I think that 
formal exception parameters should be included, or else the 
contract should allow exceptions to be named by Exception_Id as 
well as by the lexical identifier.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Exceptions

[Dmitry A. Kazakov]

On Wed, 12 Dec 2007 13:37:09 +0200, Niklas Holsti wrote:

> If the implementation with Exception_Id is so easy, I wonder that 
> the syntax with "exception" as formal parameter is not included in 
> the language. But I know that language extensions are prioritized, 
> and in fact I have never needed a formal exception parameter, 
> although I have sometimes written wrappers for instances of 
> generics just to translate an exception defined and raised by the 
> generic into some other exception for the user of the generic.
> 
> In any plan to extend Ada with exception contracts, I think that 
> formal exception parameters should be included, or else the 
> contract should allow exceptions to be named by Exception_Id as 
> well as by the lexical identifier.

The reverse, the keyword "exception" should be dropped and replaced by a
plain type name Standard.Exception. Then we would be able to pass an
exception (or an array of) wherever we wished to. (Exception_Id is IMO a
hack)

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

Re: Exceptions

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:475e8bde$0$27850$4f793bc4@news.tdc.fi...
> ...
>> And perhaps also
>>
>>    5. Exceptions as formal generic parameters.
>
> Ada has this (although it isn't obvious): just pass an
> Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec
> something like:
>
>     generic
>          My_Exception : Ada.Exceptions.Exception_Id :=
> Constraint_Error'Identity;
>     package Gen is ...

Yeah, you can do that.

But IMHO this area of the language is a mess.

Making exceptions be first-class objects would make the language
simpler, easier to implement, and more powerful.

- Bob

Re: Exceptions

[Martin Krischik]

Robert A Duff wrote:

> Why on earth would anybody write "null;" there?!

Maybe because Java has no Program_Error.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Exceptions

[Maciej Sobczak]

On 11 Gru, 09:07, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:

> For code I have control over, I agree with Bob, except I use a
> different exception; raise Programmer_Error if you've detected a bug.

I understand that this way you want to signal something much more
severe than "mere" Constraint_Error or such.
The problem is that Program_Error can be shut up by some null handler
or it can be translated to some other exception and then lose its
original weight.

Why not terminating the program right on the spot by simply:

pragma Assert (False);

?
(yes, there are compiler options to switch it off as well)

Does anybody use this strategy in regular code?
I happen to use it in test units and I find it very appropriate there.
Any thoughts on using assertions, including Assert(False), in
production code?

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Exceptions

[Robert A Duff]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Robert A Duff wrote:
>
>> Why on earth would anybody write "null;" there?!
>
> Maybe because Java has no Program_Error.

Well, it's as easy to create an unchecked exception
in Java as it is in Ada!  ;-)

- Bob

Re: Exceptions

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 11 Gru, 09:07, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>
>> For code I have control over, I agree with Bob, except I use a
>> different exception; raise Programmer_Error if you've detected a bug.
>
> I understand that this way you want to signal something much more
> severe than "mere" Constraint_Error or such.
> The problem is that Program_Error can be shut up by some null handler
> or it can be translated to some other exception and then lose its
> original weight.

The solution to "when others => null;" and the like is better
education.  Competent programmers need to know not to do that,
except in rare cases, where a big fat comment is in order.
(Unfortunately, the designers of Ada 83 made exactly this
mistake for task bodies!  And Ada 95 repeats it for
interrupt handlers.)

I don't consider Constraint_Error "mere", by the way.
It almost always represents a bug.

> Why not terminating the program right on the spot by simply:
>
> pragma Assert (False);
>
> ?

That doesn't terminate the program on the spot.
It raises Assertion_Failure.

I consider all of these:

    pragma Assert (False);
    Assert (False); -- Assert is a user-defined procedure
    raise Program_Error;
    raise Bug; -- Bug is a user-defined exception used project-wide

to be legitimate ways of reporting a self-detected bug.

There ought to be a standard predefined procedure for stopping the
program "on the spot".  Since there isn't, you can import "exit".

> (yes, there are compiler options to switch it off as well)

Indeed, it's turned off by default in GNAT (which I don't much like).

> Does anybody use this strategy in regular code?
> I happen to use it in test units and I find it very appropriate there.
> Any thoughts on using assertions, including Assert(False), in
> production code?

Nothing wrong with using assertions in production code.

- Bob

Re: Exceptions

[Maciej Sobczak]

On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:

> The solution to "when others => null;" and the like is better
> education.

Isn't it also a solution for all the presumed problems of C/C++?
Sorry, could not resist. ;-)

> I don't consider Constraint_Error "mere", by the way.
> It almost always represents a bug.

What about a situation when a user entered an input data that was
outside of legal (and documented) range? Or that caused our of range
value further down the pipe?
This is not necessarily a bug, just an indication that the value is
out of range. The exception can help to come back to the input loop
and repeat the user scenario, abandoning all the state that was
created in the meanime. This way the program does not enter into any
abnormal state.

> > Why not terminating the program right on the spot by simply:
>
> > pragma Assert (False);

> That doesn't terminate the program on the spot.
> It raises Assertion_Failure.

Right. I was somehow convinced that Assert has this magic property of
switching the world off, like the assert macro in C and C++.

> I consider all of these:
>
>     pragma Assert (False);
>     Assert (False); -- Assert is a user-defined procedure
>     raise Program_Error;
>     raise Bug; -- Bug is a user-defined exception used project-wide
>
> to be legitimate ways of reporting a self-detected bug.

OK, this sounds reasonable.

> There ought to be a standard predefined procedure for stopping the
> program "on the spot".  Since there isn't, you can import "exit".

I was wandering whether there is any standard mechanism for this.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Exceptions

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> The solution to "when others => null;" and the like is better
>> education.
>
> Isn't it also a solution for all the presumed problems of C/C++?
> Sorry, could not resist. ;-)

I see the smiley, but...  Here's a serious reply anyway:

A language design should not try to prevent people from
doing bad things.  It should try to prevent people from
doing bad things BY ACCIDENT.

The Java programmers who have been mentioned several times in this
thread -- the ones who evilly stick in do-nothing handlers -- are doing
so on purpose.  Any attempt to fix that problem via language design will
backfire.  Fixing it via education OTOH has a good chance of success.

Forgetting to handle an exception, however, is an accident.  A language
design can help there, but education will not.

>> I don't consider Constraint_Error "mere", by the way.
>> It almost always represents a bug.
>
> What about a situation when a user entered an input data that was
> outside of legal (and documented) range? Or that caused our of range
> value further down the pipe?
> This is not necessarily a bug, just an indication that the value is
> out of range. The exception can help to come back to the input loop
> and repeat the user scenario, abandoning all the state that was
> created in the meanime. This way the program does not enter into any
> abnormal state.

Well, you can't refute an "almost always" statement by giving a
counterexample.  ;-)

Yes, in the situation you mention, it's reasonable to say:

    when Constraint_Error =>
        null; -- loop back and ask user again

I've got no problem with that, so long as there's a good comment.
It should not be "when others" in this case, either.

>> There ought to be a standard predefined procedure for stopping the
>> program "on the spot".  Since there isn't, you can import "exit".
>
> I was wandering whether there is any standard mechanism for this.

You can abort the environment task.  But I'm not sure what that will do
in a multi-threaded, multi-language program -- depends on the
implementation.  Anyway, it's an ugly trick.  I'd rather be able to
portably say "Kill_Program;" or "Kill_Program(exit_code);" or something
like that.  Note that you need to think carefully about whether you want
finalizers to run.

- Bob

Re: Exceptions

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcctzmonfmn.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> > news:475e8bde$0$27850$4f793bc4@news.tdc.fi...
> > ...
> >> And perhaps also
> >>
> >>    5. Exceptions as formal generic parameters.
> >
> > Ada has this (although it isn't obvious): just pass an
> > Ada.Exceptions.Exception_Id to the generic. That is, given a generic
spec
> > something like:
> >
> >     generic
> >          My_Exception : Ada.Exceptions.Exception_Id :=
> > Constraint_Error'Identity;
> >     package Gen is ...
>
> Yeah, you can do that.
>
> But IMHO this area of the language is a mess.
>
> Making exceptions be first-class objects would make the language
> simpler, easier to implement, and more powerful.

Right, but in that case we *still* wouldn't need formal exceptions, because
formal objects would serve just as well. Which really was my point - no
sense in adding more cruft for that.

                     Randy.

Re: Exceptions

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:9f16235c-260a-460b-873c-2183c154cc0c@e25g2000prg.googlegroups.com...
> On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
...
> > I don't consider Constraint_Error "mere", by the way.
> > It almost always represents a bug.
>
> What about a situation when a user entered an input data that was
> outside of legal (and documented) range? Or that caused our of range
> value further down the pipe?
> This is not necessarily a bug, just an indication that the value is
> out of range. The exception can help to come back to the input loop
> and repeat the user scenario, abandoning all the state that was
> created in the meanime. This way the program does not enter into any
> abnormal state.

An *unhandled* Constraint_Error represents a bug - in this case, a lack of
appropriate input validation. One can handle it very locally for that
purpose, although I prefer to input values into maximum size objects and
check the range with a membership before converting it. (That way, that
there is in fact validation is clearer.)

Even the propagation of Constraint_Error represents a bug.

Exception contracts would help with detecting that, but only if the rules
were strong enough that it is possible to write reasonable code that is
exception-free. Having Java-style "unchecked exceptions" defeats the
purpose.

                                        Randy.

P.S. Sorry about the old responses just appearing now; something happened to
the news server while I was answering those on Monday, and it didn't work
again until now.

Re: Exceptions

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I don't buy the supposed need for two kinds of exceptions.

Maybe "kind" is the wrong term.  I think you want to be able to say,
"X can be raised by anything in this scope (including child packages)".
X might be Storage_Error, for example.  In fact, that should be the
default for Storage_Error -- there's no point in saying "This can
raise S_E" on every procedure in the program!

In any case, if you have checked exceptions, then you definitely need
unchecked ones.  That is, you need some way to say, "This cannot happen,
and I know that, and in this case I [think I] am smarter than the
compiler."

>... It seems to me to
> be an implicit recognition of the fact that the contracts aren't
> sufficiently useful for many kinds of subprograms. I think it would be
> better to fix the capability of the contracts (if that's possible) than to
> define a trivial way to avoid them.
>
> Once you have unchecked exceptions, the contract really doesn't tell you
> anything interesting (since it is the propagation of predefined exceptions
> that usually lead to bugs; only the rare case where the predefined exception
> is caught will tell you anything at all). Moreover, the temptation is
> overwhelming to use the unchecked kind everywhere, because it is less hassle
> and the checked kind doesn't buy that much anyway (it doesn't guarentee that
> all exceptions are handled, but only the rare few that are declared
> checked).

OK, I think you've convinced me, at least in the context of Ada,
and probably Java.

I think Constraint_Error needs to be a checked exception
-- otherwise, you miss a lot of bugs.
But pretty-much anything can raise C_E in Ada.

The solution must lie in having pre/post conditions and invariants,
and a fairly powerful way of checking them statically.  That's far
from the existing Ada.  Clearly, if:

    for I in A'Range loop
        ... A(I) ...

and:

    while X /= null loop
        ... X.all ...

require a handler for Constraint_Error, or a declaration that this
procedure can propagate it, then the feature is not terribly useful.

What I really want is something like SPARK, but with much
less restriction on features that can be used.

> It's much like the accessibility rules in Ada. They're immensely
> complicated, yet their original primary goal is completely ignored. I've
> never yet found an Ada program where I could use 'Access on an object; I
> don't even bother trying anymore. So why have all of that complication?
> (Yes, I know its useful for subprograms and tagged types, and we can't avoid
> it there.)

- Bob

Re: Exceptions

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Right, but in that case we *still* wouldn't need formal exceptions, because
> formal objects would serve just as well. Which really was my point - no
> sense in adding more cruft for that.

Exactly!  The desire for generic formal exceptions is a symptom of the
problem, to which first-class exceptions are the obvious clean
solution.

- Bob

Re: Exceptions

[Ray Blaak]

Martin Krischik <krischik@users.sourceforge.net> writes:
> Robert A Duff wrote:
> 
> > Why on earth would anybody write "null;" there?!
> 
> Maybe because Java has no Program_Error.

throw new java.lang.AssertionError("this should be impossible");

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Exceptions

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> The Java programmers who have been mentioned several times in this
> thread -- the ones who evilly stick in do-nothing handlers -- are doing
> so on purpose.  Any attempt to fix that problem via language design will
> backfire.  Fixing it via education OTOH has a good chance of success.

I used to "believe" in checked exception handling, my Ada experience being the
likely inspiration.

Long experience with Java code leads me to believe they cause more problems
then they solve, simply due to the fact that the majority of programmers are
coding at a junior or "naive" level.

So, when the compiler demands an exception handler, then by golly they provide
one -- one that simply swallows the exception with a log of the stack trace.

This is in fact far worse than not handling the exception at all, since
control flow is not aborted.

So, the junior programmer evilly stuck in a do-nothing handler, but they had
no clue they were being evil.

Note also that the theoretical correctness of whether or not checked
exceptions are better is not being disputed here -- the answer is
irrelevant. The *practical* effect of checked exceptions, at least with junior
programmers, tends, in Java at least, to cause worse results than not handling
the exception at all.

So, C#'s approach of not having checked exceptions is turning out to be a
better design decision in practice, in my experience.

Another point is to consider what one usually does with a handled
exception. Usually it is to ultimately report it or log it in some manner.
Primarily it needs to perculate up to a top level, where some sort of central
event loop can be reset. Sometimes some cleanup needs to be done, but that
cleanup often tends to be needed for any exception that is thrown, and the
exception should often be rethrown anyway so as to continue to abort the
control flow. My experience is that most code does not need to handle
exceptions at all except at well defined points in the top level.

Mind you, with the use of a non-garbage collected language like Ada, one would
need to do cleanups with exceptions more often, but that does not imply the
need to do specific exception handling.

The times I have seen the need for exception specific handling is usually to
do with error message generation. Some exceptions need to show stack traces,
some need to show different messages, some need to be shown to the user,
etc. This kind of thing is easier to centralize in a language where exceptions
are first class objects, since one can override exception behaviour
(e.g. anything extending from UserException will be shown to the user,
anything else will be logged with a stack trace, with only an "unexpected
error" shown to the user, paprticular error reasons are shown via overriding
the getMessage() method, etc.).

I note also that recent APIs for Java (e.g. XML DOM, Joda data/time, D4Bo
OODB) tend to use unchecked exceptions in their APIs, since it makes
development so much easier for writing and maintaining code against those
APIs.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Exceptions

[Ray Blaak]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> Once you have unchecked exceptions, the contract really doesn't tell you
> anything interesting (since it is the propagation of predefined exceptions
> that usually lead to bugs; only the rare case where the predefined exception
> is caught will tell you anything at all).

Even with checked exceptions the contract still doesn't help, since unchecked
exceptions are always possible in one form or another (e.g. allocation
failures, program errors, truly unexpected failures). You can't just die.

> Moreover, the temptation is overwhelming to use the unchecked kind
> everywhere, because it is less hassle and the checked kind doesn't buy that
> much anyway (it doesn't guarentee that all exceptions are handled, but only
> the rare few that are declared checked).

I see nothing wrong with following that temptation. Following that temptation
saves time.

Basically, the effort at trying to statically prove that all exceptions are
handled is a waste of time. Even if the language supports checked exceptions,
unchecked ones can still leak through.

Having a sort of "unexpected exception" policy let's you catch any surprises
reasonable, and you can always go back and tweak the code to handle any
specific ones better should that prove necessary.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Exceptions

[Randy Brukardt]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message
news:u4pem6r3t.fsf@STRIPCAPStelus.net...
...
> Mind you, with the use of a non-garbage collected language like Ada, one
would
> need to do cleanups with exceptions more often, but that does not imply
the
> need to do specific exception handling.

I generally agree with you, but there is one case where you need to do
specific exception handling: when you need to change one exception into
another.

For instance, the specification for Ada.Text_IO says that a Get of an
integer that is out of range raises Data_Error. If you write that code in
Ada (and I think most of us implementers did), you probably had to handle
Constraint_Error somewhere and then raise Data_Error instead. I find that
this sort of handler is fairly common if you use user-defined exceptions in
your packages.

                         Randy.

P.S. Ada programmers *raise* exceptions. The only thing that Ada programmers
"throw" is the trash into the trash can... ;-)

Re: Exceptions

[Randy Brukardt]

"Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message
news:uzlwe5c7t.fsf@STRIPCAPStelus.net...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> > Moreover, the temptation is overwhelming to use the unchecked kind
> > everywhere, because it is less hassle and the checked kind doesn't buy
that
> > much anyway (it doesn't guarentee that all exceptions are handled, but
only
> > the rare few that are declared checked).
>
> I see nothing wrong with following that temptation. Following that
temptation
> saves time.
>
> Basically, the effort at trying to statically prove that all exceptions
are
> handled is a waste of time. Even if the language supports checked
exceptions,
> unchecked ones can still leak through.

That was my point; ther language *should not have* unchecked exceptions if
it is going to bother with any checking. Then there is no possibility of
"sneaking through" (modulo compiler or hardware bugs). Yes, you'd have to
declare Storage_Error on (nearly) every routine (and I think that is a good
thing in such an environment). Such a language would require substantial
static analysis at compile-time (but that is practical these days), and
would be a lot closer to the promise of "no bugs if it compiles" (Ada
already gets quite a bit of the way there).

Still I have to wonder if many people would want to use such a language
(writing code is necessarily harder), and even if they did, if anyone could
stand the language definition effort.

                                 Randy.

Re: Exceptions

[Ray Blaak]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> I generally agree with you, but there is one case where you need to do
> specific exception handling: when you need to change one exception into
> another.

Ok, it has to be said again: exceptions need to be first class objects.

Changing an exception into another is trivial in most languages, typically by
wrapping it with another of the desired kind.

Ada's difficulties with manipulating exceptions are completely self induced.

> P.S. Ada programmers *raise* exceptions. The only thing that Ada programmers
> "throw" is the trash into the trash can... ;-)

Real languages don't have a trash can. There is a janitor in the background
cleaning everything up. Exceptions are the only thing left to throw >-).

Ada is a pretty good language. Garbage collection is a step up the
evolutionary ladder though, and needs to be available within Ada as well,
perhaps under programmer control to be disabled when necessary.  Google some
previous threads for my arguments on this topic.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Exceptions

[Ray Blaak]

"Randy Brukardt" <randy@rrsoftware.com> writes:
> That was my point; ther language *should not have* unchecked exceptions if
> it is going to bother with any checking. Then there is no possibility of
> "sneaking through" (modulo compiler or hardware bugs). Yes, you'd have to
> declare Storage_Error on (nearly) every routine (and I think that is a good
> thing in such an environment). Such a language would require substantial
> static analysis at compile-time (but that is practical these days), and
> would be a lot closer to the promise of "no bugs if it compiles" (Ada
> already gets quite a bit of the way there).
> 
> Still I have to wonder if many people would want to use such a language
> (writing code is necessarily harder), and even if they did, if anyone could
> stand the language definition effort.

Well that's just it. No one would use it since they wouldn't be able to get
any work done. They would be spending too much time writing exception
declarations and handlers.

And for what? What does having Storage_Error declared everywhere buy you? You
knew that going in. And how would you handle it? Crash or log it. You can do
that in one place at the top level.

The vast majority of those forced handlers would be tedious and repetitive,
excactly the kind of thing that can be automated, and thus made invisible; in
other words, to be turned into unchecked exceptions.

Another way to view unchecked exceptions is that they are the language's way
of having an implied exception "can raise" contracts declared everywhere.

Programming languages are a tool for *people* to instruct computers what to
do, not the other way round.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.

Re: Exceptions

[Georg Bauhaus]

Ray Blaak wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> I generally agree with you, but there is one case where you need to do
>> specific exception handling: when you need to change one exception into
>> another.
> 
> Ok, it has to be said again: exceptions need to be first class objects.

Or, exceptions need to stay the way they are for the exceptional case of
something going wrong(!) but we need a mechanism for safely signaling
information up the call chain in a specially controlled fashion
(the algorithmic use of "exception objects").

Re: Exceptions

[Robert A Duff]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> Long experience with Java code leads me to believe they cause more problems
> then they solve, simply due to the fact that the majority of programmers are
> coding at a junior or "naive" level.
>
> So, when the compiler demands an exception handler, then by golly they
> provide one -- one that simply swallows the exception with a log of
> the stack trace.

This is what I don't get.  I know there are lots of not-so-good
programmers around, but how hard could it be to teach that "junior"
programmer how to do this particular thing right?  It's not "rocket
science".  ;-)  And if the programmer can't learn this much, maybe
they don't have much aptitude for programming in the first place.

> This is in fact far worse than not handling the exception at all, since
> control flow is not aborted.

Indeed.  That's why exceptions are a good idea in the first place --
their default behavior is to STOP, as opposed to forging ahead blindly
causing who-knows-what chaos.

> So, the junior programmer evilly stuck in a do-nothing handler, but they had
> no clue they were being evil.

... and the senior programmer reviews the code, and gives the junior one
a few tips, and pretty soon ... <oh, never mind> ;-)

- Bob

Re: Exceptions

[Dmitry A. Kazakov]

On Fri, 14 Dec 2007 12:29:01 -0500, Robert A Duff wrote:

> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
> 
>> Long experience with Java code leads me to believe they cause more problems
>> then they solve, simply due to the fact that the majority of programmers are
>> coding at a junior or "naive" level.
>>
>> So, when the compiler demands an exception handler, then by golly they
>> provide one -- one that simply swallows the exception with a log of
>> the stack trace.
> 
> This is what I don't get.  I know there are lots of not-so-good
> programmers around, but how hard could it be to teach that "junior"
> programmer how to do this particular thing right?  It's not "rocket
> science".  ;-)  And if the programmer can't learn this much, maybe
> they don't have much aptitude for programming in the first place.

The actual problem is exceptions misused for debugging. A "senior"
programmer would compensate this wrong design, while a "junior" one would
just add more mess.

For debugging there were enough to have some sort of "stop at once"
statement (with breaking into the debugger.)

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

Re: Exceptions

[Ray Blaak]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:
>> So, when the compiler demands an exception handler, then by golly they
>> provide one -- one that simply swallows the exception with a log of
>> the stack trace.
>
> This is what I don't get.  I know there are lots of not-so-good
> programmers around, but how hard could it be to teach that "junior"
> programmer how to do this particular thing right?  It's not "rocket
> science".  ;-)  And if the programmer can't learn this much, maybe
> they don't have much aptitude for programming in the first place.

The problem is that you are being logical :-).

For some unexplained reason, this bad practice simply keeps on happening. The
only thing I can think of is that the base human instinct is to go "what is
the fastest, cheapest way to shut the compiler up?".

So, one catches the exception, of course. Now what to do with it? You have to
note something useful, after all. Ah! Stack trace! To the log! Done!

Forgot to rethrow...whoops...

> ... and the senior programmer reviews the code, and gives the junior one
> a few tips, and pretty soon ... <oh, never mind> ;-)

In the end there is too much energy expended by the senior programmer
refighting the same arguments over and over.

Eventually a language is chosen where these battles simply become irrelevant.

-- 
Cheers,                                                                 Bork Bork
Ray Blaak
rblaaSTRIPCAPS@telus.net