February 12, 2003
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
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
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
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
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