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

(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))) ]

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

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))) ]

"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.

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.
>
>

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

"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...

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