View mode: basic / threaded / horizontal-split · Log in · Help
February 12, 2003
static exception checking?
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.
February 13, 2003
Re: static exception checking?
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.
February 13, 2003
Re: static exception checking?
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.
> 
>
February 14, 2003
Re: static exception checking?
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
February 14, 2003
Re: static exception checking?
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
Top | Discussion index | About this forum | D home