Ada exceptions. unchecked?

Ada exceptions. unchecked?

[steve_H]

I have thought that Ada exceptions were unchecked, is this correct?

I saw this below:

http://www.mindview.net/Etc/Discussions/CheckedExceptions

"To clarify a couple of points in your article, Ada does not have any 
form of exception specification, and so does not have a 
checked/unchecked model."

could some Ada expert comment if the above statment is correct or not?

Re: Ada exceptions. unchecked?

[Ted Dennison]

nma124@hotmail.com (steve_H) wrote in message news:<8db3d6c8.0206112300.3965a62b@posting.google.com>...
> I have thought that Ada exceptions were unchecked, is this correct?
> 
> I saw this below:
> 
> http://www.mindview.net/Etc/Discussions/CheckedExceptions
> 
> "To clarify a couple of points in your article, Ada does not have any 
> form of exception specification, and so does not have a 
> checked/unchecked model."
> 
> could some Ada expert comment if the above statment is correct or not?

It looks to me like his "checked exceptions" means that the compiler
forces a caller to provide an explicit check for all exceptions listed
in the spec of a routine as being thrown by that routine. If that is
the case (I'm not a Java expert, so I don't know) then Ada indeed does
not have "checked exceptions". There is no language-defined way to
specify what exceptions are raised by a routine in Ada, as there is in
C++ (and Java?).

I would certianly agree that requiring an exception handler for every
possible exception in every single encolsing block around a procedure
call in Ada would be a pain.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: Ada exceptions. unchecked?

[Larry Kilgallen]

In article <8db3d6c8.0206112300.3965a62b@posting.google.com>, nma124@hotmail.com (steve_H) writes:
> I have thought that Ada exceptions were unchecked, is this correct?

What do you mean by "unchecked" ?

Re: Ada exceptions. unchecked?

[Mark Johnson]

Larry Kilgallen wrote:
> 
> In article <8db3d6c8.0206112300.3965a62b@posting.google.com>, nma124@hotmail.com (steve_H) writes:
> > I have thought that Ada exceptions were unchecked, is this correct?
> 
> What do you mean by "unchecked" ?

After a quick review of the web site he referenced, I believe he is
referring to the need in Java to either...
 - catch the exception
 - declare that the exception is thrown
Adding it to Ada at this point would break a lot of code (but also
likely FIX a lot of code when implemented).
  --Mark

Re: Ada exceptions. unchecked?

[Larry Kilgallen]

In article <3D0750F1.7A12342@raytheon.com>, Mark Johnson <mark_h_johnson@raytheon.com> writes:
> Larry Kilgallen wrote:
>> 
>> In article <8db3d6c8.0206112300.3965a62b@posting.google.com>, nma124@hotmail.com (steve_H) writes:
>> > I have thought that Ada exceptions were unchecked, is this correct?
>> 
>> What do you mean by "unchecked" ?
> 
> After a quick review of the web site he referenced, I believe he is
> referring to the need in Java to either...
>  - catch the exception
>  - declare that the exception is thrown
> Adding it to Ada at this point would break a lot of code (but also
> likely FIX a lot of code when implemented).

But what about all those exceptions like Program Error that might be
signalled other than by the explicit choice of the programmer ?  Are
there two classes of exceptions ?

Re: Ada exceptions. unchecked?

[Darren New]

Larry Kilgallen wrote:
> But what about all those exceptions like Program Error that might be
> signalled other than by the explicit choice of the programmer ?  Are
> there two classes of exceptions ?

Yes. Checked and Unchecked. :-) And the programmer is allowed to declare
unchecked exceptions. (And I think they're actually called something like
Exception and RunTimeException or some such.)

In my experience, the vast majority of Java code winds up catching all the
checked exceptions and turning them into unchecked exceptions before
rethrowing them. This is because there are a lot of callbacks declared not
to throw exceptions, and a lot of library routines that do throw exceptions.

For a sloppy and imprecise example,
  application's main calls file_open_dialog,
    file_open_dialog calls gui_button_handler
      gui_button_handler calls application's load_file
        application's load_file calls Java's read, which throws EOF_error.

At this point, the application's load_file has to get the error back to the
application's main routine to be handled. But the gui_button_handler doesn't
declare that it can throw EOF_error, because the button hasn't anything to
do with files. So the normal technique is to create a new unchecked
exception and pass the checked exception in the constructor, then throw
that, then catch it in the main routine and unwrap it.

That is to say, one tends to do the same thing with checked exceptions in
Java as one does with collections: cast everything to the same type, then
recast it to the type you expect later. I've found the checking really
doesn't help much at all, except to those C programmers who when reading a
file assume you never hit the end of file early, and who assume a file is
never deleted between the time you take a listing of the directory and the
time you try to open a file, and etc.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[Dale Stanbrough]

Darren New wrote:

> For a sloppy and imprecise example,
>   application's main calls file_open_dialog,
>     file_open_dialog calls gui_button_handler
>       gui_button_handler calls application's load_file
>         application's load_file calls Java's read, which throws EOF_error.
> 
> At this point, the application's load_file has to get the error back to the
> application's main routine to be handled. But the gui_button_handler doesn't
> declare that it can throw EOF_error, because the button hasn't anything to
> do with files. So the normal technique is to create a new unchecked
> exception and pass the checked exception in the constructor, then throw
> that, then catch it in the main routine and unwrap it.

Note that this problem would also apply if exceptions had
to be declared in a subprogram, and those subprograms were used
in a generic.

For example I have a convenience generic to iterate over each line
of a file - you pass a procedure that does the work on each line.
Clearly the generic can't know what exceptions the procedure could
generate.

Dale

Re: Ada exceptions. unchecked?

[Hyman Rosen]

Dale Stanbrough wrote:
> For example I have a convenience generic to iterate over each line
> of a file - you pass a procedure that does the work on each line.
> Clearly the generic can't know what exceptions the procedure could
> generate.

Same problem in C++. Except for throwing nothing, C++ experts
have come to the conclusion that exception specifications are
useless.

I think they're also misguided. The point of using exceptions
for signalling errors is to communicate information between the
point where the error happens and the point at which someone is
ready to deal with it. The path in between is traversed quietly,
with destructors (or Controlled objects) handling the cleanup of
resources as scopes are closed down. There is no reason for code
along the path to have to explicitly mention everything that can
possibly pass through it.

Re: Ada exceptions. unchecked?

[Darren New]

Hyman Rosen wrote:
> I think they're also misguided. The point of using exceptions
> for signalling errors is to communicate information between the
> point where the error happens and the point at which someone is
> ready to deal with it. 

I suspect the point in Java was to *force* you to deal with it. How many C
programmers write something like

  buffer = malloc(size);
  fill_in_buffer(buffer, size);
  write(handle, buffer, size);

without checking that malloc succeeded or that the write actually wrote the
right number of characters? If malloc() and write() threw exceptions that
you were *required* to catch or declare, you couldn't get away with this.
The real problem is callbacks and exceptions, not just the declared
exeptions.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[Hyman Rosen]

Darren New wrote:
> I suspect the point in Java was to *force* you to deal with it.
 > How many C programmers write something like
> 
>   buffer = malloc(size);
>   fill_in_buffer(buffer, size);
>   write(handle, buffer, size);
> 
> without checking that malloc succeeded or that the write actually wrote the
> right number of characters? If malloc() and write() threw exceptions that
> you were *required* to catch or declare, you couldn't get away with this.
> The real problem is callbacks and exceptions, not just the declared
> exeptions.

The point is to force the program to deal with problems.
So in your example, malloc will throw an exception if it
fails to allocate memory, and write could throw if it is
given a null pointer. That's fine. And at some point in
the program we could have an exception handler that deals
with this. But why does every intervening function in the
call tree have to state for the record that it knows that
something it calls may throw such an exception, if it is
not the place where the exception is handled?

Re: Ada exceptions. unchecked?

[Darren New]

Hyman Rosen wrote:
> But why does every intervening function in the
> call tree have to state for the record that it knows that
> something it calls may throw such an exception, if it is
> not the place where the exception is handled?

Because it prevents the programmer from ignoring the problem. Note, I didn't
say it prevents the *program* from ignoring it, but the *programmer*.

That is, with checked exceptions, you can't call malloc() without checking
the result, even if every single time you test the program, you manage to
allocate enough memory. 
In other words, it's much the same way that Java refuses to compile somthing
like

int x;
if (y) {x = 5;}
blah(x); /* because x *might* be uninitialized, even if the programmer
            knows that Y will always be true at this point. */

The problem with checked exceptions is that when you're using a lot of
libraries with callbacks and such, the checked exceptions require you to
handle the exception in the *wrong* place. It's difficult to get around in
any clean way, unlike the uninitialized-variable problem.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[Hyman Rosen]

Darren New wrote:
> Because it prevents the programmer from ignoring the problem. Note, I didn't
> say it prevents the *program* from ignoring it, but the *programmer*.
> 
> That is, with checked exceptions, you can't call malloc() without checking
> the result, even if every single time you test the program, you manage to
> allocate enough memory.

Are we talking about the same thing here? The whole point
of exceptions is exactly to call malloc without checking
the result. With exception-based error handling, code is
written as if errors never happen, and resource allocation
is done with objects which release the resource when their
lifetime ends. Then if an error does happen, the exception
propogates out to a handler which usually deals with the
situation in a high-level fashion, and allocated resources
between the point of the exception and the handler are
cleaned up.

Re: Ada exceptions. unchecked?

[Darren New]

Hyman Rosen wrote:
> 
> Darren New wrote:
> > Because it prevents the programmer from ignoring the problem. Note, I didn't
> > say it prevents the *program* from ignoring it, but the *programmer*.
> >
> > That is, with checked exceptions, you can't call malloc() without checking
> > the result, even if every single time you test the program, you manage to
> > allocate enough memory.
> 
> Are we talking about the same thing here? The whole point
> of exceptions is exactly to call malloc without checking
> the result. 

I guess it depends on your philosophy. If the creators of Java were looking
at C and saying "what are common errors that people make" I can see this
being the idea.

> With exception-based error handling, code is
> written as if errors never happen, and resource allocation
> is done with objects which release the resource when their
> lifetime ends.

Well, yes, in languages where objects have a definite lifetime, this is
true. Java isn't like that. Java, instead, has garbage collection. Look at
Eiffel for yet another take on exception-based error handling.

I'm not saying Java's take on this is right, and I'm not saying it's the
best way to handle it. I'm just saying that's how it is. I am explicitly
*not* trying to convince you it's good. I don't even think it's good myself.

> Then if an error does happen, the exception
> propogates out to a handler which usually deals with the
> situation in a high-level fashion, and allocated resources
> between the point of the exception and the handler are
> cleaned up.

Yes, and by declaring what exceptions get thrown, you're telling people who
are calling your library "hey, here's the exceptions you have to handle in a
high-level fashion." Works great, until someone else writes part of the
code, and then they call one of your routines.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[Hyman Rosen]

Darren New wrote:
> Yes, and by declaring what exceptions get thrown, you're telling people who
> are calling your library "hey, here's the exceptions you have to handle in a
> high-level fashion." Works great, until someone else writes part of the
> code, and then they call one of your routines.

Yes, the problem is that the program, or the programmer,
needs to know what exceptions to handle, but not every
routine needs to know it. It seems to me that this should
be accomplished through documentation.

Re: Ada exceptions. unchecked?

[Stephen J. Bevan]

Hyman Rosen <hyrosen@mail.com> writes:
> Yes, the problem is that the program, or the programmer,
> needs to know what exceptions to handle, but not every
> routine needs to know it. It seems to me that this should
> be accomplished through documentation.

The Java designers decided that, like types, exceptions must be
statically checked by the compiler***.  They presumably did this for
the same reason that they want types statically checked: to catch as
many errors at compile time as possible (i.e. avoid an exception being
thrown for which there is no handler).

It is possible that they went too far with this and that statically
checking exceptions causes more pain than it is worth.  However, if
you ask a Smalltalk or Lisp programmer they'll tell you that
statically checking *types* (as is done in Ada) causes more pain than
it is worth it would be better to use documentation and/or test cases.

*** There is a loophole: RuntimeException (and any subclasses) can be
    thrown without listing it in a method signature.

Re: Ada exceptions. unchecked?

[Simon Wright]

Mark Johnson <mark_h_johnson@raytheon.com> writes:

> Larry Kilgallen wrote:
> > 
> > In article <8db3d6c8.0206112300.3965a62b@posting.google.com>, nma124@hotmail.com (steve_H) writes:
> > > I have thought that Ada exceptions were unchecked, is this correct?
> > 
> > What do you mean by "unchecked" ?
> 
> After a quick review of the web site he referenced, I believe he is
> referring to the need in Java to either...
>  - catch the exception
>  - declare that the exception is thrown

or (quite often) declare the exception as being of a type
(RunTimeException???) that you don't have to quote in the "throws"
section ..

Re: Ada exceptions. unchecked?

[Gisle Sælensminde]

In article <3D0750F1.7A12342@raytheon.com>, Mark Johnson wrote:
> Larry Kilgallen wrote:
>> 
>> In article <8db3d6c8.0206112300.3965a62b@posting.google.com>, nma124@hotmail.com (steve_H) writes:
>> > I have thought that Ada exceptions were unchecked, is this correct?
>> 
>> What do you mean by "unchecked" ?
> 
> After a quick review of the web site he referenced, I believe he is
> referring to the need in Java to either...
>  - catch the exception
>  - declare that the exception is thrown
> Adding it to Ada at this point would break a lot of code (but also
> likely FIX a lot of code when implemented).
>   --Mark

Checked exceptions as in Java is in fact a horrible idea. If you assume
that the program is designed with error handling in mind from the start,
it could work, but in practice you will discover at some point that some
lowlevel error condition the highlevel need to handle. In that case 
all the methods in the entire call tree need to be changed. If the 
application is sufficiently large, you simply can't do that. 

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

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

Re: Ada exceptions. unchecked?

[Mark Johnson]

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

The point you make addresses a typical application problem. You have a
higher level module attempting to recover from some low level
implementation detail that should be transparent to it. I can argue that
the one of the abstractions used to build the application is broken -
not checked exceptions. Checked exceptions helped you find out that the
design or implementation is broke - fix it.

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

Re: Ada exceptions. unchecked?

[Gisle Sælensminde]

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

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

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

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

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

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

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

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

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

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

Re: Ada exceptions. unchecked?

[Darren New]

Gisle Sælensminde wrote:
> The problem was that it was
> not possible to add new signatures to tousands of soubroutines in a reasonable
> time, and redesign would take even longer time.

Or worse... it's not your code, and you don't even have the source.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[Simon Wright]

Gisle S�lensminde <gisle@apal.ii.uib.no> writes:

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

I suppose it's not possible to insist that people never propagate
exceptions that don't make sense in their caller's world view?

Re: Ada exceptions. unchecked?

[AG]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vu1o48tnf.fsf@pushface.org...
> Gisle S�lensminde <gisle@apal.ii.uib.no> writes:
>
> > The problem is that exception handling at one layer possibly must be
> > handled in parts of the program where it does not make sense, and
> > that make programmers to do such code "to get the job done". My
> > point is that the strictness of java exceptions is
> > counter-productive.
>
> I suppose it's not possible to insist that people never propagate
> exceptions that don't make sense in their caller's world view?

It may not be possible but it would be a good idea if it could be done.
After all, if an exception (or, more generally, any result of execution)
does not make sense to the caller, what's the point of sending it back?

Re: Ada exceptions. unchecked?

[Darren New]

AG wrote:
> It may not be possible but it would be a good idea if it could be done.
> After all, if an exception (or, more generally, any result of execution)
> does not make sense to the caller, what's the point of sending it back?

Because it makes sense to whoever called the caller.

If A calls B, and B calls C, and C throws an except that B doesn't
understand how to handle (or that didn't even exist when B was compiled) but
A does, then A nevertheless cannot conveniently get the exception back in
Java.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[AG]

"Darren New" <dnew@san.rr.com> wrote in message
news:3D0BCFC5.A7B2D4C0@san.rr.com...
> AG wrote:
> > It may not be possible but it would be a good idea if it could be done.
> > After all, if an exception (or, more generally, any result of execution)
> > does not make sense to the caller, what's the point of sending it back?
>
> Because it makes sense to whoever called the caller.

But in that case the caller is just an intermediary which doesn't really
know
or care of what to do with the result (if any) or how to handle the
exceptions.
I guess I meant the "caller" that is the real user of the result, not just
some
pass-through function.

>
> If A calls B, and B calls C, and C throws an except that B doesn't
> understand how to handle (or that didn't even exist when B was compiled)
but
> A does, then A nevertheless cannot conveniently get the exception back in
> Java.

Point taken, but that's just Java problem, isn't it?

Re: Ada exceptions. unchecked?

[Darren New]

AG wrote:
> Point taken, but that's just Java problem, isn't it?

Yes. Well, it's the "checked exceptions" problem. Any language with checked
exceptions will have this problem. At some point, *every* exception doesn't
make sense in the caller's world view, or you wouldn't have a top-level
exception handler built into the run-time of a language. :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Ada exceptions. unchecked?

[Charles Lindsey]

In <x7vu1o48tnf.fsf@pushface.org> Simon Wright <simon@pushface.org> writes:

>I suppose it's not possible to insist that people never propagate
>exceptions that don't make sense in their caller's world view?

No. In my caller's world view, the thing that just happened is an utter
catastrophe that can noway be fixed locally. The only thing I (the caller)
can think of is to abort the program and call in the guy who wrote it.

But up at the top, where they require this program to run for months on
end, they HAVE to do something. Even if they cannot understand the
exception, it is always at least possible automatically to restart the
system from scratch and at least keep some sort of service going.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Re: Ada exceptions. unchecked?

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> I suppose it's not possible to insist that people never propagate
> exceptions that don't make sense in their caller's world view?

When I write my code, I have _no idea_ who might be calling it, so I
have _no idea_ what might make sense in their world view. So I throw
exceptions, and let them decide.

-- 
-- Stephe

Re: Ada exceptions. unchecked?

[Wes Groleau]

> > I suppose it's not possible to insist that people never propagate
> > exceptions that don't make sense in their caller's world view?
> 
> When I write my code, I have _no idea_ who might be calling it, so I
> have _no idea_ what might make sense in their world view. So I throw
> exceptions, and let them decide.

To put it another way, the proper response to an exception
in a general purpose subprogram depends on what the inputs
and outputs are being used for.  No way am I going to write

  exception

     when Constraint_Error =>
        
        if Caller                     = Task_A   and
           Caller_Line_Number         = 517      and
           Item_That_Was_Out_Of_Range = First_Parameter then

            .....

:-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau