Even if a lack of a throws clause implied no exception thrown,
> you will still get idiots who will declare they throw the exception base class.  The compiler cannot fix that.

No it can, writing 'throws' in the decleration is not alone making the
compiler happy. You must actually throw it somewhere, or call a function in
your body that throws this exception, or else you've at least a warning if
not an error. So if you declare the exceptoin base class in the throws
clause you must also throw it somewhere.

> I still say you should hound the API developer, or use a different API by someone a little less idiotic.

I used to have C++ projects that suddendly crashed by the costumer because some code part threw an exception that was not catched. Whats more important quick hacks or stable projects?

Axel Kittenberger wrote in message <9mv24r$r8k$1@digitaldaemon.com>...
>I used to have C++ projects that suddendly crashed by the costumer because some code part threw an exception that was not catched. Whats more important quick hacks or stable projects?


It's common for C and C++ code to crash because the code failed to test for the error return from a function. Even longtime professional programmers make this error. By having errors signalled by throwing an exception, they cannot be ignored by default. If there is no code to catch the exception, the startup code installs an exception handler to print out the error message for the exception (all exceptions are defined to have an explanatory error message associated with them).

For batch programs, this in itself will be adequate for most uses.

For non-batch programs, at least you get a reasonable error message and graceful exit when the program fails, instead of the C approach of a random crash.

Axel Kittenberger wrote:
> 
> Even if a lack of a throws clause implied no exception thrown,
> > you will still get idiots who will declare they throw the exception base class.  The compiler cannot fix that.
> 
> No it can, writing 'throws' in the decleration is not alone making the compiler happy. You must actually throw it somewhere, or call a function in your body that throws this exception, or else you've at least a warning if not an error. So if you declare the exceptoin base class in the throws clause you must also throw it somewhere.

	This is were we differ then.  I do believe a function should be able to
claim it throws an exception that it in fact does not.  This is why I
replied to my first message on this thread.  The basic reason is that a
standard API may allow for a given type of exception, when not all
implementation of that standard will throw that exception.  Either the
API user has to use version statements in his throws clause (if that is
even possible) or he will not be able to code to the standard and still
use the more robust implementations of that standard.
	Requiring a function to actually throw every exception in it throws
clause will be the source of many problems even for the most anal of
developers.  An unused exception is not like an unused variable in a
function.  Requiring a function to throw every exception in it throws
clause is more like requiring a function with a return type of int to
return every value from int.min() to int.max() at some point in its
code.

> > I still say you should hound the API developer, or use a different API by someone a little less idiotic.
> 
> I used to have C++ projects that suddendly crashed by the costumer because some code part threw an exception that was not catched. Whats more important quick hacks or stable projects?

	My experience tells me both.  My proposal would in fact satisfy the
requirements of both.  It would require allowing exceptions in the
throws clause that aren't in fact thrown, it would require that a
function be allowed to throw an exception if it is not in the throws
clause as long as it is derived from one of the types in the throws
clause.  This already assumes that there is a shared base class for all
exceptions.  The spec calls it Error.

	class e1 : Error {} // Error is the exception base class
	class e2 : e1 {}
	class e3 : e1 {}

	// I can throw nothing
	void f() throws();

	// I could throw anything including, but not limited to e1, e2 & e3
	void g() throws(Error);

	// I could throw anything including, but not limited to e1, e2 & e3
	void h();

	// I could throw any subclass of e1 including, but not limited to e2 &
e3
	// I cannot throw Error or anything else not derived from e1
	void i() throws(e1);

	// I could throw any subclass of e2 including, but not limited to e3
	// I cannot throw e1 or Error or anything else not derived from e2
	void j() throws(e2);

	// I could throw any subclass of e2 or e3
	// I cannot throw e1 or Error or anything else not derived from e2 or
e3
	void k() throws(e2, e3);

	try{
		f();
		g();
		h();
		i();
		j();
		k();
	}catch(Error){
		// ALL exceptions WILL be caught here,
		// without exception  :-)
	}

All of the exceptions thrown by these functions could be caught by a
'catch(Error)' because all exceptions MUST be derived from Error or one
of its descendants.  Nothing can slip through.  It is bullet proof and
air tight.  No exceptions.
	The lazy can be lazy.  The non lazy can be non lazy, even when using
code written by a lazy developer.  The non lazy would probably have an
easier time if he used code exclusively from other non lazy programmers.
Even then he has to deal with the idiots and he has the tools he needs
to do so.

Dan

> This is were we differ then.  I do believe a function should be able to
> claim it throws an exception that it in fact does not.  This is why I
> replied to my first message on this thread.  The basic reason is that a
> standard API may allow for a given type of exception, when not all
> implementation of that standard will throw that exception.  Either the
> API user has to use version statements in his throws clause (if that is
> even possible) or he will not be able to code to the standard and still
> use the more robust implementations of that standard.
> Requiring a function to actually throw every exception in it throws
> clause will be the source of many problems even for the most anal of
> developers.  An unused exception is not like an unused variable in a
> function.  Requiring a function to throw every exception in it throws
> clause is more like requiring a function with a return type of int to
> return every value from int.min() to int.max() at some point in its
> code.

True, I thought futher over that, in the matter of polymorphism requiring to throw all throws declared things is a horror.

> My experience tells me both.  My proposal would in fact satisfy the requirements of both.  It would require allowing exceptions in the throws clause that aren't in fact thrown, it would require that a function be allowed to throw an exception if it is not in the throws clause as long as it is derived from one of the types in the throws clause.

I don't think this will benefit in the matter of readability. Why should one want to throw a child of the throws clause? Catching through inheritence by parents, okay. But throwing childs?

This already assumes that there is a shared base class for all

> The lazy can be lazy.  The non lazy can be non lazy, even when using code written by a lazy developer.

Thats another main objective we might differ. Does the language encorage projects written by a single author, or for multiple authors. This statment goes against projects where more than one code is envolved, and this is exactly the place most modern language approach at. Look who uses C++ succesfull in practice, most of these who do it but an additial coding rules upen C++ and force themself to a defined subset of the language, project teams where every member is allowed to use all features of C++ like he finds them are usually not so successfull, because C++ is bloated of features. Now I darkly remember what was the mission statment of D? " Programming managers who are forced to rely on C programming style guidelines to avoid common C bugs." So this goes against the lazy and non lazy approach :o)

- Axel

> It's common for C and C++ code to crash because the code failed to test for the error return from a function. Even longtime professional programmers make this error.

Okay now how many people do check on the return value for fclose() :o)

> By having errors signalled by throwing an
> exception, they cannot be ignored by default. If there is no code to catch
> the exception, the startup code installs an exception handler to print out
> the error message for the exception (all exceptions are defined to have an
> explanatory error message associated with them).

Well I used MSVC in the past, an the application just halted with an exit code. Not message, nothing. But mabye I just did something wrong.

And actually this is the runtime vs. compiletime approval. Why should a error have to be discovered at runtime if it could be tracked at compiletime already? Like uncatched excpetions. And honestly through all economic non high-security software projects we must admit that there are really some code parts that go out untested, like some cases to reaction of certain malfunctions. No 'normal' software project can effort to go through a profiler supported branch decision test analyses high security software goes through. Just take a worst case exception, "NuclearCoreMeltdownException", okay one code piece forgot to catch it and to start emergency shutdown sequence. The compiler doesn't complain because some guys want to do quick hacks without having to write syntatic catch-sugar. Now the application terminates with a nice NuclearCoreMeltdownException raised in code module XYZ line 245 is uncatched, application terminated with exit code -1. But now who starts the emergency sequence?

I know this example is very hyperbolical, since software used in this fields is tested through other means as we're used to. But I think you can image what I think about, take in example fclose(), no body with local filesystems thinks about closing a file could fail, but with network filesystems it can, and a really good program should at least inform the user that his file is not saved, and possibly lost. Okay fclose is a bad example as 99% of people ignore it's return value, myself included :(

But I think you can imagine what I ment with comiletime vs. runtime security.

- Axel

I think your suggestion and reasoning is pretty good. -Walter

Dan Hursh wrote in message <3B9326BB.44475274@infonet.isl.net>...
>Axel Kittenberger wrote:
>>
>> Even if a lack of a throws clause implied no exception thrown,
>> > you will still get idiots who will declare they throw the exception
base
>> > class.  The compiler cannot fix that.
>>
>> No it can, writing 'throws' in the decleration is not alone making the compiler happy. You must actually throw it somewhere, or call a function
in
>> your body that throws this exception, or else you've at least a warning
if
>> not an error. So if you declare the exceptoin base class in the throws clause you must also throw it somewhere.
>
> This is were we differ then.  I do believe a function should be able to
>claim it throws an exception that it in fact does not.  This is why I replied to my first message on this thread.  The basic reason is that a standard API may allow for a given type of exception, when not all implementation of that standard will throw that exception.  Either the API user has to use version statements in his throws clause (if that is even possible) or he will not be able to code to the standard and still use the more robust implementations of that standard.
> Requiring a function to actually throw every exception in it throws
>clause will be the source of many problems even for the most anal of developers.  An unused exception is not like an unused variable in a function.  Requiring a function to throw every exception in it throws clause is more like requiring a function with a return type of int to return every value from int.min() to int.max() at some point in its code.
>
>> > I still say you should hound the API developer, or use a different API
by
>> > someone a little less idiotic.
>>
>> I used to have C++ projects that suddendly crashed by the costumer
because
>> some code part threw an exception that was not catched. Whats more important quick hacks or stable projects?
>
> My experience tells me both.  My proposal would in fact satisfy the
>requirements of both.  It would require allowing exceptions in the throws clause that aren't in fact thrown, it would require that a function be allowed to throw an exception if it is not in the throws clause as long as it is derived from one of the types in the throws clause.  This already assumes that there is a shared base class for all exceptions.  The spec calls it Error.
>
> class e1 : Error {} // Error is the exception base class
> class e2 : e1 {}
> class e3 : e1 {}
>
> // I can throw nothing
> void f() throws();
>
> // I could throw anything including, but not limited to e1, e2 & e3
> void g() throws(Error);
>
> // I could throw anything including, but not limited to e1, e2 & e3
> void h();
>
> // I could throw any subclass of e1 including, but not limited to e2 &
>e3
> // I cannot throw Error or anything else not derived from e1
> void i() throws(e1);
>
> // I could throw any subclass of e2 including, but not limited to e3
> // I cannot throw e1 or Error or anything else not derived from e2
> void j() throws(e2);
>
> // I could throw any subclass of e2 or e3
> // I cannot throw e1 or Error or anything else not derived from e2 or
>e3
> void k() throws(e2, e3);
>
> try{
> f();
> g();
> h();
> i();
> j();
> k();
> }catch(Error){
> // ALL exceptions WILL be caught here,
> // without exception  :-)
> }
>
>All of the exceptions thrown by these functions could be caught by a 'catch(Error)' because all exceptions MUST be derived from Error or one of its descendants.  Nothing can slip through.  It is bullet proof and air tight.  No exceptions.
> The lazy can be lazy.  The non lazy can be non lazy, even when using
>code written by a lazy developer.  The non lazy would probably have an easier time if he used code exclusively from other non lazy programmers. Even then he has to deal with the idiots and he has the tools he needs to do so.
>
>Dan

Axel Kittenberger wrote:
> > My experience tells me both.  My proposal would in fact satisfy the requirements of both.  It would require allowing exceptions in the throws clause that aren't in fact thrown, it would require that a function be allowed to throw an exception if it is not in the throws clause as long as it is derived from one of the types in the throws clause.
> 
> I don't think this will benefit in the matter of readability. Why should one want to throw a child of the throws clause? Catching through inheritence by parents, okay. But throwing childs?
> 
> This already assumes that there is a shared base class for all

	This is a concession to the fact that some venders will implement
things in a way that will allow they to return more granular error
information than standard designers had anticipated or felt they could
expect from all vendors.  If a standard API stated that a given method
X() could throw NetworkException in the case of network problems, a
given vendor could subclass that exception to provide different forms of
network exceptions to differentiate between cases that their platform
can correct and those that can't be helped.
	This could allow people who are willing to tie themselves to the
platform increased granularity of error detection and possibly allow
them to react better to certain exceptional situations.  Developers who
code to the standard would not be affected by this increased
granularity.  Developers who do use the extra exceptions would have to
find out about them somewhere other than the throws clause, which is sub
optimal for them.
	I guess there would be other ways around this one too, but it feels
most natural to me.  I was just assuming that the exceptions in the
throws clause might make their way into a function signature somehow,
and I would not want someone who writes to a standard to get bitten
because some one else was an over achiever in error detection.

> > The lazy can be lazy.  The non lazy can be non lazy, even when using code written by a lazy developer.
> 
> Thats another main objective we might differ. Does the language encorage
> projects written by a single author, or for multiple authors. This statment
> goes against projects where more than one code is envolved, and this is
> exactly the place most modern language approach at. Look who uses C++
> succesfull in practice, most of these who do it but an additial coding
> rules upen C++ and force themself to a defined subset of the language,
> project teams where every member is allowed to use all features of C++ like
> he finds them are usually not so successfull, because C++ is bloated of
> features. Now I darkly remember what was the mission statment of D?
> " Programming managers who are forced to rely on C programming style
> guidelines to avoid common C bugs."
> So this goes against the lazy and non lazy approach :o)

	This is the biggest difference I guess.  It is good to plan things so
good practices can be handled and enforced by the language.  Large
projects will benefit from it.  On the other hand, most of my experience
has shown me that the quick fix tools and simple utilities are just as
important as huge billion line programs.  I would also guess that a
number of scientists writing simulations would not be as interested in
these strict features.  They would want to be aware of errors, but they
would be just as happy to let the simulation die, so they can correct
the error.  It's the difference between shipping a product and doing in
house, batch style work.  Not every task requires rock solid stability
and it is not practical to impose such constrains on everyone.  It is
necessary that to provide the tools that will allow people to easily get
stability if they want it, but there needs to be room for the tradeoffs
that have to happen in the real world.
	We could say that D is only for "Programming managers who are forced to
rely on C programming style guidelines to avoid common C bugs" but I
suspect that such a stance would make D just another language that is
only used by a few large companies use for a short period of time.
	I guess the thing I like about have the exception handling that I've
been whining about is that you can take a function by a lazy developer,
add a throws clause, and the compiler will tell you (through error
messages) what exceptions you need to handle or pass on.  So it is easy
to start working on a chuck of code without paying much attention to
error handling, and when you are ready to clamp down, it would be pretty
easy.

Dan

Axel Kittenberger wrote:
> 
> > It's common for C and C++ code to crash because the code failed to test for the error return from a function. Even longtime professional programmers make this error.
> 
> Okay now how many people do check on the return value for fclose()
> :o)

	I believe I've mention in one of the other "exceptions" threads that I
was anal.  This is what I mean.  I will admit, I don't check it every
time, I do check it often, even in perl.  Go ahead. Laugh!

> > By having errors signalled by throwing an
> > exception, they cannot be ignored by default. If there is no code to catch
> > the exception, the startup code installs an exception handler to print out
> > the error message for the exception (all exceptions are defined to have an
> > explanatory error message associated with them).
> 
> Well I used MSVC in the past, an the application just halted with an exit code. Not message, nothing. But mabye I just did something wrong.

	Probably not.  I've had the same thing in UNIX.  I think my C++
implementation just called abort on uncaught exceptions.  Java dumps
huge stack traces that fall somewhere between rude and terrifying to the
unwashed masses.  It sounds like D is going to require behavior of the
runtime that is likely to be a little less anti-social.

> And actually this is the runtime vs. compiletime approval. Why should a error have to be discovered at runtime if it could be tracked at compiletime already? Like uncatched excpetions.

  The issue is that uncaught exceptions are not necessarily an error.
It sounds like D will allow the exception to be the means to pass on an
error message and die which is reasonable behavior in a large number of
cases.  (If only you could give it the exit status too.  hint hint)

> And honestly through all
> economic non high-security software projects we must admit that there are
> really some code parts that go out untested, like some cases to reaction of
> certain malfunctions. No 'normal' software project can effort to go through
> a profiler supported branch decision test analyses high security software
> goes through. Just take a worst case exception,
> "NuclearCoreMeltdownException", okay one code piece forgot to catch it and
> to start emergency shutdown sequence. The compiler doesn't complain because
> some guys want to do quick hacks without having to write syntatic
> catch-sugar. Now the application terminates with a nice
> NuclearCoreMeltdownException raised in code module XYZ line 245 is
> uncatched, application terminated with exit code -1. But now who starts the
> emergency sequence?

	OK.  So this isn't one of those cases where returning a message and
exit status would be sufficient.

> I know this example is very hyperbolical, since software used in this fields is tested through other means as we're used to.

	True, but I like the idea of a nuclear meltdown being handled
automatically by an exception.  It just sounds so routine.

> But I think you can
> image what I think about, take in example fclose(), no body with
> local filesystems thinks about closing a file could fail, but with network
> filesystems it can, and a really good program should at least inform the
> user that his file is not saved, and possibly lost. Okay fclose is a bad
> example as 99% of people ignore it's return value, myself included :(
> 
> But I think you can imagine what I ment with comiletime vs. runtime security.

	Yes, there should be a way to find out at compiler time if there are
any uncaught exceptions.  There are project that would definitely use
that.  But there a lot of genuinely useful programming tasks for with
overly strict exception rules would be a burden that bares no benefits.
Not everyone is building a Sherman tank.  (Or a Nuke Plant for that
matter.)  There must be room for tradeoffs.

Dan

PS:  I still like the idea of a nuclear meltdown being handled by a mere exception.  I can't imagine what it would be like to write the code that monitor the situation and just determine "hmm... The core is melting.  I guess I'll throw an exception.  My work is done."  :-)

> This is the biggest difference I guess.  It is good to plan things so good practices can be handled and enforced by the language.  Large projects will benefit from it.  On the other hand, most of my experience has shown me that the quick fix tools and simple utilities are just as important as huge billion line programs.  I would also guess that a number of scientists writing simulations would not be as interested in these strict features.

That's the point, and thats a principle decision languages have to do. From what I read from the walters specs I had the impression he targeted his language to be thought for use by million line programs not as a ideal quick hack tool. For quick hacks a lot of scrip languages are already pretty ideal, or?

- Axel

Axel Kittenberger wrote:
> 
> > This is the biggest difference I guess.  It is good to plan things so good practices can be handled and enforced by the language.  Large projects will benefit from it.  On the other hand, most of my experience has shown me that the quick fix tools and simple utilities are just as important as huge billion line programs.  I would also guess that a number of scientists writing simulations would not be as interested in these strict features.
> 
> That's the point, and thats a principle decision languages have to do. From what I read from the walters specs I had the impression he targeted his language to be thought for use by million line programs not as a ideal quick hack tool. For quick hacks a lot of scrip languages are already pretty ideal, or?
> 
> - Axel

	True.  I was just going off some of his comments I've seen on this
group.  I'm guessing he's after as much middle ground in this area as
possible without making a complete sacrifice in error handling.  Even
with the compromise, D would be worlds better than C.  I'm still of the
opinion that it would be no worse than java functionally speaking.  In
any case, I've gone on longer about this than I ever intended to.

Dan