• Toby Miller (12/12) Feb 12 2003 Is there any support for compiler checked exception handling?
• Ilya Minkov (26/41) Feb 12 2003 Why, exceptions not handled by the user are actually quite normal!
• Toby Miller (33/87) Feb 12 2003 Yes, that works fine for your example. But there are times when you
• Antti Sykari (9/31) Feb 13 2003 Looks good. Sprinkling "throws" clauses everywhere can be a pain, as
• C (6/9) Feb 13 2003 How about:

"Toby Miller" <toby.miller pobox.com> writes:

Is there any support for compiler checked exception handling?

Exceptions are a great feature but they tend to get ignored by programmer's
if they are not part of a function's signature.  For example, portions of
the C++ STL throw exceptions but I don't remember where or when and,
therefore, I never even think about writing handlers.

I think some might argue against this because they don't want to add
handler's to all functions.  You can avoid this by adding unhandled
exceptions to the signature of your function.  And for quick-and-dirty
programs, simply add a "throws everything" to the function signature (this
is the default for C++ functions).

At the very least, it would be nice if the compiler would generate warnings
about unhandled (or propagated in the signature) exceptions.

Ilya Minkov <midiclub 8ung.at> writes:

Why, exceptions not handled by the user are actually quite normal!

Unlike unhandled error return codes in C, which get forgotten and then 
someday an application crashes in a mysterious manner, an exception can 
be really harmless. It gives you at least an error message which makes 
sense. And the application doesn't need to crash. I almost never had to 
use exception handling in my Delphi code, because there's enough of it 
in the library.

Example: you have a GUI application comsisting of an input field, some 
output field and a button. You are expected to enter a number as an 
input. If you press enter, the GUI library runs your function which:
  - uses the input field's properties to extract the input string;
  - uses library routine to convert it into integer;
  - makes some calculations on the number;
  - writes result into the output field.

Now, taken you enter "nonsense" into the input and press the button. The 
conversion routine raises an exception of type, indicating that it's a 
conversion error and holding a description string: "'nonsense' is not a 
valid integer value." The GUI library button's event processor catches 
this exception and displays an error message generated from the 
description string and continues the program execution loop normally.

Furthermore, since this behaviour is already put into a basic class of 
all graphic controls, if someone creates a library of his own graphic 
controls he would usually subclass this generic and would get all the 
benefits without having to handle errors explicitly either.

-i.


Toby Miller wrote:
 Is there any support for compiler checked exception handling?
 
 Exceptions are a great feature but they tend to get ignored by programmer's
 if they are not part of a function's signature.  For example, portions of
 the C++ STL throw exceptions but I don't remember where or when and,
 therefore, I never even think about writing handlers.
 
 I think some might argue against this because they don't want to add
 handler's to all functions.  You can avoid this by adding unhandled
 exceptions to the signature of your function.  And for quick-and-dirty
 programs, simply add a "throws everything" to the function signature (this
 is the default for C++ functions).
 
 At the very least, it would be nice if the compiler would generate warnings
 about unhandled (or propagated in the signature) exceptions.

Toby Miller <toby.miller pobox.com> writes:

Yes, that works fine for your example.  But there are times when you 
need to handle error conditions more "intelligently" (for lack of a 
better word).  It is not always acceptable to do high-level 
catch-all-and-log error handling.  Sometimes you need to try to recover 
from an error condition at a lower level.  Imagine the flight control 
system for a missile.  There is no user around to ask what to do and it 
is unacceptable to quit.

I am not saying that the compiler should force every function to catch 
every possible exception of all the functions that it calls.  Some you 
will want to catch at a higher level.  That's what is great about 
exceptions, you can handle them at the level that makes sense.  In a 
complex system that makes use of many third party libraries it can 
become tedious to keep track of which exceptions have been caught and at 
what level.  And it would be nice to know at compile time that all 
exceptions have been handled at the appropriate level.  Instead of just 
running and waiting for an exception to occur.

Of course, all applications are not created equal.  With many 
applications it IS acceptable to print an error message and quit or 
prompt the user for help.  You do not want to burden these types of 
applications w/ any overhead.  But for applications that must be more 
robust it would be great if the compiler could provide some assistance.


some thing like:

void foo1() {...}
/* Can throw anything, don't bother me w/ warnings
about uncaught exceptions. */

void foo2 throws (Error1, Error2) {..}
/* Now I'm asking the compiler to help me.
Warn me if anything other then Error1 or Error2 can make
it out of this function. */


In my humble opinion this provides the best of both worlds.  You can 
avoid any overhead in applications that do not require it.  But you can 
"ask" for the compiler's assistance when it is required.


Ilya Minkov wrote:
 Why, exceptions not handled by the user are actually quite normal!
 
 Unlike unhandled error return codes in C, which get forgotten and then 
 someday an application crashes in a mysterious manner, an exception can 
 be really harmless. It gives you at least an error message which makes 
 sense. And the application doesn't need to crash. I almost never had to 
 use exception handling in my Delphi code, because there's enough of it 
 in the library.
 
 Example: you have a GUI application comsisting of an input field, some 
 output field and a button. You are expected to enter a number as an 
 input. If you press enter, the GUI library runs your function which:
  - uses the input field's properties to extract the input string;
  - uses library routine to convert it into integer;
  - makes some calculations on the number;
  - writes result into the output field.
 
 Now, taken you enter "nonsense" into the input and press the button. The 
 conversion routine raises an exception of type, indicating that it's a 
 conversion error and holding a description string: "'nonsense' is not a 
 valid integer value." The GUI library button's event processor catches 
 this exception and displays an error message generated from the 
 description string and continues the program execution loop normally.
 
 Furthermore, since this behaviour is already put into a basic class of 
 all graphic controls, if someone creates a library of his own graphic 
 controls he would usually subclass this generic and would get all the 
 benefits without having to handle errors explicitly either.
 
 -i.
 
 
 Toby Miller wrote:
 
 Is there any support for compiler checked exception handling?

 Exceptions are a great feature but they tend to get ignored by 
 programmer's
 if they are not part of a function's signature.  For example, portions of
 the C++ STL throw exceptions but I don't remember where or when and,
 therefore, I never even think about writing handlers.

 I think some might argue against this because they don't want to add
 handler's to all functions.  You can avoid this by adding unhandled
 exceptions to the signature of your function.  And for quick-and-dirty
 programs, simply add a "throws everything" to the function signature 
 (this
 is the default for C++ functions).

 At the very least, it would be nice if the compiler would generate 
 warnings
 about unhandled (or propagated in the signature) exceptions.

 
 

Antti Sykari <jsykari gamma.hut.fi> writes:

Toby Miller <toby.miller pobox.com> writes:

 I am not saying that the compiler should force every function to catch
 every possible exception of all the functions that it calls.  Some you
 will want to catch at a higher level.  That's what is great about
 exceptions, you can handle them at the level that makes sense.  In a
 complex system that makes use of many third party libraries it can
 become tedious to keep track of which exceptions have been caught and
 at what level.  And it would be nice to know at compile time that all
 exceptions have been handled at the appropriate level.  Instead of
 just running and waiting for an exception to occur.

 Of course, all applications are not created equal.  With many
 applications it IS acceptable to print an error message and quit or
 prompt the user for help.  You do not want to burden these types of
 applications w/ any overhead.  But for applications that must be more
 robust it would be great if the compiler could provide some assistance.

 some thing like:

 void foo1() {...}
 /* Can throw anything, don't bother me w/ warnings
 about uncaught exceptions. */

 void foo2 throws (Error1, Error2) {..}
 /* Now I'm asking the compiler to help me.
 Warn me if anything other then Error1 or Error2 can make
 it out of this function. */

Looks good.  Sprinkling "throws" clauses everywhere can be a pain, as
any Java programmer can tell.  So the default of "may throw anything"
sounds reasonable.

But throws declarations can be useful in mission-critical
applications; so maybe this is one of the features to appear in 2.0 :)

A declaration with the "don't throw" semantics would be needed, as
well.  (An empty throws declaration, perhaps?)

-Antti

C <blackmarlin asean-mail.com> writes:

Antti Sykari wrote:

void foo2 throws (Error1, Error2) {..}


 A declaration with the "don't throw" semantics would be needed, as
 well.  (An empty throws declaration, perhaps?)

How about:

void wombat ( ... ) throws ( null ) { ... }

or just

void wombat ( ... ) throws null { ... }

C 2003/2/14