• Walter (3/3) Nov 01 2001 Given the many debates here about it for D, here's a great link to an es...
• Russ Lewis (29/29) Nov 01 2001 (grit teeth) The essay is very persuasive. I will (halfway) change cam...
• John Nagle (29/34) Nov 05 2001 Much of the problem with C++ exceptions comes from the fact
• Russ Lewis (10/37) Nov 05 2001 Agreed. This would seem to be easy to do by including a "next" pointer ...
• Pavel Minayev (19/46) Nov 05 2001 In general, I agree. However, there's no need to force to derive
• Walter (6/53) Nov 06 2001 Yes, it is a good idea.
• Russell Borogove (5/21) Nov 06 2001 You should be ashamed of yourself for trying to undermine the
• Pavel \"EvilOne\" Minayev (6/9) Nov 06 2001 Definitely not! A dump of registers should be enough for
• a (9/22) Nov 06 2001 You have a point. Maybe we can compromise and get something close to

"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

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

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

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

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

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

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

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

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