www.digitalmars.com         C & C++   DMDScript  

D - Bruce Eckel's Essay on Checked Exceptions

reply "Walter" <walter digitalmars.com> writes:
Given the many debates here about it for D, here's a great link to an essay
on it.

http://www.mindview.net/Etc/Discussions/CheckedExceptions
Nov 01 2001
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
(grit teeth)  The essay is very persuasive.  I will (halfway) change camps on
this.

As he points out, checked exceptions (known around this NG as "strict exception
specification") tends to push programmers toward "swallowing" large numbers of
exceptions, which is exactly the opposite of what exceptions are about.  In
fact, it's a return to the C days of "don't bother with checking the return
code".

This is a Bad Thing.

OTOH, I really think that it is critical that D provide the syntax tools to
define good APIs between various program components in a system.  Without
checked exceptions, you have functions that "do something, but might also throw
just about anything."

This is also a Bad Thing.

IMHO, the language needs space for both.  Two solutions present themselves.
* Don't allow strict-specified functions to call non-strictly specified
functions.  While technically very feasible, it is hard for the programmers.
This will cause programmers to swallow exceptions, just like before.  Or else
they'll abandon exception specifications altogether.
* Allow the compiler and linker to dynamically generate exception
specifications at build time.  This is far more difficult to achieve, but far
better for the programmers.  Unspecified functions are given a generated
specification when they are built; this is included in the link information
when building object files.  Specified functions can use this generated
information to know what they can call and what they can't.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Nov 01 2001
prev sibling parent reply John Nagle <nagle animats.com> writes:
Walter wrote:
 
 Given the many debates here about it for D, here's a great link to an essay
 on it.
 
 http://www.mindview.net/Etc/Discussions/CheckedExceptions

Much of the problem with C++ exceptions comes from the fact that any type can be thrown as an exception. Exceptions should all be derived from some base exception class, so that a handler for the base class will get all of them and will get some basic error info. C++ has "catch(...)", but you can't extract any info from "...". Some convention as to the minimum info attached to the exception is necessary. If you have a standard exception base type, the question becomes not whether you want to catch an exception, but how much information you want to extract from the ones you do catch. That's easier on the programmer while remaining useful. As for what should be in the standard exception type, I'd suggest that along with exception info, the standard exception type should be able to link to another exception type. Thus, when you catch an error and want to throw another exception, the newly thrown exception should link to the old one, so that the low-level info isn't lost. Then, at higher levels, the exception can be processed and useful information reported to the user or logged. This would lead to error messages like Printing to printer "pr1" was unsuccessful because the font "Zowie" could not be loaded because the font package reported an I/O error because the networking module detected an error because the connection to "128.5.31.4" was closed because "Destination unreachable" was returned from the network. John Nagle
Nov 05 2001
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
John Nagle wrote:

 Walter wrote:
 Given the many debates here about it for D, here's a great link to an essay
 on it.

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

Much of the problem with C++ exceptions comes from the fact that any type can be thrown as an exception. Exceptions should all be derived from some base exception class, so that a handler for the base class will get all of them and will get some basic error info. C++ has "catch(...)", but you can't extract any info from "...". Some convention as to the minimum info attached to the exception is necessary. If you have a standard exception base type, the question becomes not whether you want to catch an exception, but how much information you want to extract from the ones you do catch. That's easier on the programmer while remaining useful. As for what should be in the standard exception type, I'd suggest that along with exception info, the standard exception type should be able to link to another exception type. Thus, when you catch an error and want to throw another exception, the newly thrown exception should link to the old one, so that the low-level info isn't lost. Then, at higher levels, the exception can be processed and useful information reported to the user or logged. This would lead to error messages like

Agreed. This would seem to be easy to do by including a "next" pointer in each exception object, which points to the underlying reason for the current exception. The exception constructor would accept a pointer to an exception as one of its arguments (defaulting to NULL). -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Nov 05 2001
prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"John Nagle" <nagle animats.com> wrote in message
news:3BE7579C.408C30A5 animats.com...

    Much of the problem with C++ exceptions comes from the fact
 that any type can be thrown as an exception.  Exceptions should all
 be derived from some base exception class, so that a handler for
 the base class will get all of them and will get some basic
 error info.  C++ has "catch(...)", but you can't extract any
 info from "...".  Some convention as to the minimum info
 attached to the exception is necessary.

In general, I agree. However, there's no need to force to derive all exceptions from a single class. Why not just declare class Exception and _strongly encourage_ its use. This way, those who want to use simple types as exceptions are let to do so and use catch(...), while more advanced people like us =) can simply catch(Exception& e). This is the way it's done in Delphi, AFAIK, and it works.
    If you have a standard exception base type, the question
 becomes not whether you want to catch an exception, but
 how much information you want to extract from the ones
 you do catch.  That's easier on the programmer while
 remaining useful.

Hmm... I hope this doesn't mean that my fav syntax - omitting argument name in catch blocks - is going to disappear? Sometimes I just don't care why exception of that concrete type happened, because I know for sure that at this point there could be only one reason for it.
    As for what should be in the standard exception type,
 I'd suggest that along with exception info,
 the standard exception type should be able to link to
 another exception type.  Thus, when you catch an error
 and want to throw another exception, the newly thrown
 exception should link to the old one, so that the low-level
 info isn't lost.  Then, at higher levels, the exception
 can be processed and useful information reported to the
 user or logged.  This would lead to error messages like

 Printing to printer "pr1" was unsuccessful
 because the font "Zowie" could not be loaded
 because the font package reported an I/O error
 because the networking module detected an error
 because the connection to "128.5.31.4" was closed
 because "Destination unreachable" was returned from the network.

Never thought of anything like that, and I really like the idea! With this, debugging programs would be much easier, if debugger dumps such a chain. If exceptions would also know about the line of the code they were thrown from, this would greatly reduce the number of breakpoints that I usually use to debug my programs.
Nov 05 2001
parent "Walter" <walter digitalmars.com> writes:
Yes, it is a good idea.

BTW, D only allows class objects to be thrown, not ints or longs or
whatever. There will be a base class Exception with some minimal info in
it - a next pointer sounds like a great addition.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9s836p$rg2$1 digitaldaemon.com...
 "John Nagle" <nagle animats.com> wrote in message
 news:3BE7579C.408C30A5 animats.com...

    Much of the problem with C++ exceptions comes from the fact
 that any type can be thrown as an exception.  Exceptions should all
 be derived from some base exception class, so that a handler for
 the base class will get all of them and will get some basic
 error info.  C++ has "catch(...)", but you can't extract any
 info from "...".  Some convention as to the minimum info
 attached to the exception is necessary.

In general, I agree. However, there's no need to force to derive all exceptions from a single class. Why not just declare class Exception and _strongly encourage_ its use. This way, those who want to use simple types as exceptions are let to do so and use catch(...), while more advanced people like us =) can simply catch(Exception& e). This is the way it's done in Delphi, AFAIK, and it works.
    If you have a standard exception base type, the question
 becomes not whether you want to catch an exception, but
 how much information you want to extract from the ones
 you do catch.  That's easier on the programmer while
 remaining useful.

Hmm... I hope this doesn't mean that my fav syntax - omitting argument name in catch blocks - is going to disappear? Sometimes I just don't care why exception of that concrete type happened, because I know for sure that at this point there could be only one reason for it.
    As for what should be in the standard exception type,
 I'd suggest that along with exception info,
 the standard exception type should be able to link to
 another exception type.  Thus, when you catch an error
 and want to throw another exception, the newly thrown
 exception should link to the old one, so that the low-level
 info isn't lost.  Then, at higher levels, the exception
 can be processed and useful information reported to the
 user or logged.  This would lead to error messages like

 Printing to printer "pr1" was unsuccessful
 because the font "Zowie" could not be loaded
 because the font package reported an I/O error
 because the networking module detected an error
 because the connection to "128.5.31.4" was closed
 because "Destination unreachable" was returned from the network.

Never thought of anything like that, and I really like the idea! With this, debugging programs would be much easier, if debugger dumps such a chain. If exceptions would also know about the line of the code they were thrown from, this would greatly reduce the number of breakpoints that I usually use to debug my programs.

Nov 06 2001
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
John Nagle wrote:
    As for what should be in the standard exception type,
 I'd suggest that along with exception info,
 the standard exception type should be able to link to
 another exception type.  Thus, when you catch an error
 and want to throw another exception, the newly thrown
 exception should link to the old one, so that the low-level
 info isn't lost.  Then, at higher levels, the exception
 can be processed and useful information reported to the
 user or logged.  This would lead to error messages like
 
         Printing to printer "pr1" was unsuccessful
         because the font "Zowie" could not be loaded
         because the font package reported an I/O error
         because the networking module detected an error
         because the connection to "128.5.31.4" was closed
         because "Destination unreachable" was returned from the network.

You should be ashamed of yourself for trying to undermine the great tradition of useless, cryptic error messages. Surely it's more proper to print "error 17" in such a case. -RB
Nov 06 2001
parent reply "Pavel \"EvilOne\" Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message

 You should be ashamed of yourself for trying to undermine the
 great tradition of useless, cryptic error messages. Surely it's
 more proper to print "error 17" in such a case.

Definitely not! A dump of registers should be enough for any more or less advanced user to figure out what went wrong, no? In fact, sometimes I think BSOD is even the more intuitive approach to the problem...
Nov 06 2001
parent a <a b.c> writes:
Pavel \"EvilOne\" Minayev wrote:
 
 "Russell Borogove" <kaleja estarcion.com> wrote in message
 
 You should be ashamed of yourself for trying to undermine the
 great tradition of useless, cryptic error messages. Surely it's
 more proper to print "error 17" in such a case.

Definitely not! A dump of registers should be enough for any more or less advanced user to figure out what went wrong, no? In fact, sometimes I think BSOD is even the more intuitive approach to the problem...

You have a point. Maybe we can compromise and get something close to Java's style of exception traces, where you get hundreds of lines of the exception stack referencing code in library class files for which you do not have access the source code. We could maybe dump this full screen (on a blue field if you like) or as full screen as the runtime can get away with. (Some OSes make things difficult by not letting a single program usurp to console. Dan
Nov 06 2001