Exceptions

Exceptions

[howell]

I while back, I posted the following request to the net; attached are
the replies I recieved.  Thanks to those that replied!  I'm hoping that this
posting might stimulate more discussion on exception-handling issues
(e.g., CLU and "Exceptional C"s language support for denoting potential
exceptions from a unit, or paramterized exceptions...).
Thanks again,

    Chuck Howell
    MITRE, Mail Stop Z-645
    7525 Colshire Drive
    McLean, VA 22102-3481
    howell@community-chest.mitre.org

--------
From: mcvax!ukc!dcl-cs!aber-cs!pcg@uunet.uu.net  (Piercarlo Grandi)
Subject: Exception handling models

In article <8905021917.AA06033@starbase> howell@STARBASE.MITRE.ORG (Chuck Howell) writes:
    I'm interested in alternative exception handling models (e.g., Bertrand
    Myer's arguments on "disciplined exceptions" in _Object-oriented
    Software Construction_) and various idioms & conventions for use with
    existing Ada exception handling facilities.

I have long held that exception handling does not exist; an exception is
always the result of a missing case in some part of a program, i.e. the
program not computing a total function wrt its input data domain.

Exception "handling" is just adding in the appropriate places calls to
procedures to define the missing cases; such procedures whould be
dynamically scoped, so that they can be redefined dynamically.

In other words: "raise" should be replaced by a call to a dynamically
scoped procedure; dynmically scoped procedures should be added to the
language (a trivial exercise).

The issue of non local control transfer, which in the present exception
handling facility is wrongly and inextricably tied to exception handling,
should be provided as an orthogonal mechanism, as not all exception
"handlers" want to terminate with a non local goto, and not all uses of non
local gotos are in exception handlers.

I have posted a few months ago in comp.lang.c++ a C++ class that implements,
using constructors and destructors, dynamically scoped procedures as
exception handlers. It cannot be done as easily in Ada, without changing
the language a bit.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
----------------------------------------------------------

Return-Path: <tom%prg.oxford.ac.uk@NSFNET-RELAY.AC.UK>
Date:    Mon, 12 Jun 89 12:23:23 bst
From: Tom Thomson <tom%prg.oxford.ac.uk@NSFNET-RELAY.AC.UK>
To: howell%starbase.mitre.org@NSFNET-RELAY.AC.UK
Subject: Exception Handling Models

Two aspects that I care about:-
i) have to have containment, so that I can correct the error locally (inside 
   abstraction where it is detected) and avoid passing the exception to my
   user; but have to be able to pass exceptions on where appropriate. 
ii) separate the tasks of providing diagnostic information (eg trend information
    for preventative maintenance/component replacement) from those concerned
    with containment and recovery (eg correcting a single bit failure in a store
    with hamming codes, as opposed to logging the occurrence); the latter can do
    without being cluttered up with the former, and the former may need to be
    switchable independently of the latter.
 
At a slightly more aspect level of modelling, I believe strongly in in-line
exception handling. However this requires a language with a really good type
system (so that the values arising from exceptions can be typed) with much
type checking at run time, including the ability for code to discriminate on
the type of the data it's operating on. There was some work on this in the
Alvey Flagship project - - ICL & IC put exception values into the functional
language HOPE+ but it was never really taken very far or exploited much.
-----------------------------------------------------------
Return-Path: <emery@aries.mitre.org>
Date: Sun, 7 May 89 19:39:17 EDT
From: emery@aries.mitre.org (David Emery)
To: howell@starbase.mitre.org
Subject: Re:  exception models
Cc: emery@aries.mitre.org

i've often wished for exceptions with parameters (and exceptions AS parameters,
but that's another story)).  The basic model would probably not 'hurt' the
language, but would trash implementations.  
	here's some syntax ideas:
		raise an_exception(param => value);

		when an_exception =>
			if an_exception.param = value then ...

declaration syntax is a bit messier...
		an_exception : exception (param : its_type);

				dave

-------------------------------------------------------------------

Exceptions

[David Erickson]

I have a few questions related to implementation of exceptions in Ada:

Can I assume that any block with an exception handler will require an
activation record at run-time (as will blocks with declarations, procedures,
functions and packages)?

Exception handling appears to be inherently inefficient, since the entire
dynamic chain may have to be searched, checking each activation for an
appropriate handler (including activations which have no handler). Are
there any optimizations which are normally used to improve this search
process?

Since exception declarations obey static scoping rules, but the search
for exception handlers follows dynamic links, an exception can go out of
and back into scope (see Barnes pg. 181 for an example).  How are names
resolved in such a way that two exceptions with the same name, declared
in different parts of the program, do not get confused? 

I would also appreciate any references to articles which address
Ada implementation issues.

-Dave Erickson

Re: Exceptions

[Jerry Callen]

In article <9103061724.AA02582@libra.cs.nps.navy.mil> erickson@taurus.cs.nps.navy.mil (David Erickson) writes:
>Can I assume that any block with an exception handler will require an
>activation record at run-time (as will blocks with declarations, procedures,
>functions and packages)?

No, you can't assume that; it depends upon the implementation. Every compiler
I've worked with imposed no runtime overhead for entering and leaving
the scope of an exception handler. This is done by having tables (organized
in various ways, depending upon the implementation) that relate a range of
addresses with exception handlers. The pc is used to search the tables.

>Exception handling appears to be inherently inefficient, since the entire
>dynamic chain may have to be searched, checking each activation for an
>appropriate handler (including activations which have no handler).

It's possible to do this checking very quickly and combine it with unwinding
the stack. But, yes, you do have to pay for exception handling when an
exception occurs.

>Since exception declarations obey static scoping rules, but the search
>for exception handlers follows dynamic links, an exception can go out of
>and back into scope (see Barnes pg. 181 for an example).  How are names
>resolved in such a way that two exceptions with the same name, declared
>in different parts of the program, do not get confused? 

The "thing" that represents an exception is (in all the compilers I've used)
not the exception name itself, but rather the _address_ of a string
containing the name. Identical names are represented by multiple copies
of the name string; since the addresses are different, there is no confusion.

>-Dave Erickson

-- Jerry Callen
   jcallen@encore.com

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

[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

[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

[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

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

[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: 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

[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: 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: 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

[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: 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: 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

[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

[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

[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: 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: 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]

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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]

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

[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

[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: 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

[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

[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

[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: 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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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: 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

[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: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:
> 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

[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