www.digitalmars.com         C & C++   DMDScript  

D - Praise, Contract Programming, and Exceptions

reply Eric Gerlach <egerlach canada.com> writes:
Hello all,

(Author's note: This started out as a much shorter post that was meant 
to go in another thread... but it kept growing and growing, like Jack's 
beanstalk.)

First of all, Walter, I'd like to applaud you and your wonderful 
creation.  D is a language that shows some real promise as an industry 
standard.  I'm very, very excited about being able to try it eventually.

I think that above and beyond all the other improvements of the 
language, D's strongest feature is how it encourages robust programming. 
   Adding contracts (in/out/invariant) as a language construct is a 
great idea.  All too often a function that someone else writes doesn't 
do exactly what you thought it would for a boundary case, and having an 
easy way to know that it's their function and not your code screwing up 
would be wonderful.  I also love the idea of unit testing built into the 
classes.  In my experience, it won't get done well otherwise :)

However, I don't think D takes contracts far enough.  I think that all 
of a function's behaviour should be able to be described in the 
contract. Specifically, not having a 'throws' clause in a language that 
*encourages* throwing exceptions is suicide for the robustness that D 
appears to give.

I'm not going to reiterate all of the reasons to have 'throws' here, 
because I think they have been well enough stated in the threads: 
"throws?" and "Exception specification?"  But I am going to say that it 
is essential to providing the full and complete contract to a function.

When programming by contract, there are always 2 parties to the 
contract, the user and the implementor.  The implementor sets out a set 
of requirements and says "If these requirements are fulfilled, then I 
will do this!" and presents a set of results.  Breaking a contract goes 
two ways.  If the user does not meet the requirements, the contract is 
broken, and the implementor is under no obligation to fulfill it. 
However, if the implementor fails to finish the results, they have 
broken the contract, and the user will not be happy.

Now, let's take a rather funny hypothetical situation:  Implementors and 
users (the coders, not the code) will be fined $100 every time they 
break a contract.  Therefore, both implementors and users will want to 
keep their contracts all the time to avoid being fined.  But the 
implementors are in a bind.  Let's say that the 'connect()' function's 
contract says: "Call me, and I will connect to the server!"  What if the 
network is down?  It's not the connect() function's fault, but that 
coder will be fined because he broke the contract with the user.

Exceptions are the way out.  They allow an implementor to say: "Call me, 
and I will connect to the server EXCEPT if the network is down, or it's 
Tuesday!"  Now the implementor isn't held liable if the network is down. 
  Rejoice!  He doesn't get fined!

But without a 'throws' clause in a function declaration, the implementor 
isn't able to do this.  The 'connect()' function isn't able to give a 
complete contract to the world on how to use it.

The bottom line is that the 'throws' clause is necessary to provide 
complete contract programming.  If it isn't going to be in the language, 
you might as well get rid of all the contract programming constructs 
(in, out, invariant), as they lose much of their meaning, and only 
provide weak contracts.

Now, a disclaimer:  This is my only major plea about D.  I love the rest 
of the language.  If D catches on, it will be a Very Good Thing.

Cheers,

Eric

P.S. I'm going to make another post in a minute about some more ideas 
for exceptions
P.P.S. After that I'll make a post about a few more small things
Aug 25 2001
next sibling parent reply Eric Gerlach <egerlach canada.com> writes:
In anticipation of those that disagree with a semi-mandatory 'throws' 
clause, I'm going to take some arguments from a "better than C++" 
exception implementation, Java.

One of the concerns people have with making exceptions mandatory is the 
need to then either catch every possible exception, or specify it in 
your throws declaration.  Now while this is true, it's not such a bad 
thing.  Java deals with it nicely in two ways.

To understand the first method, read section 11.2 (including 11.2.1 and 
11.2.2) in the Java Language Speccification to be found at:



(I strongly encourage reading the entire section 11, it's not that long)

Java allows RuntimeExceptions and Errors not to be declared in the 
throws, because those ones either are unidentifiable at compile time, or 
are serious and rare enough to bypass the decalaration rule.  All others 
must be, and I'd argue should be, based on my previous post.

The second method is documented in Java's documentation on Throwable:

http://java.sun.com/j2se/1.4/docs/api/java/lang/Throwable.html

There's a bit in the middle that talks about 'chaining' of exceptions, 
which allows an exception to know what exception caused it to be thrown. 
  Essentially what it allows is this (from the page):

try {
   lowLevelOp();
} catch LowLevelException(le) {
   throw new HighLevelException(le);  // Chaining-aware constructor
}

Then the code catching the HighLevelException(he) can call he.getCause() 
to get the LowLevelException.  That way, all sorts of low level network 
exceptions could be abstracted to NetworkException at a higher level 
with a chain down to the lower-level exception. Anyways, seek out that 
part and read it.  Good stuff.

I hope this addresses some of the concers that people have had with this 
clause in previous posts.

Cheers,

Eric
Aug 25 2001
parent reply "Bradeeoh" <bradeeoh crosswinds.net> writes:
I've been doing an INCREDIBLY large amount of Java programming lately, and I
just want to say that I knew this, and because of my experience with it,
know how invaluabl it is.  I want to second absolutely every thing you said
in your first post and the follow up and say that, indeed, the throws clause
is completely neccesary for real, complete contracted programming (or some
substitution thereof) and is even fairly critical outside of contracts (ie,
Java)

Of the many reasons programming in Java can go so much quicker and smoother,
I think the throws concept requiring Exceptions to be caught is one of them,
because the compiler KNOWS there may be an exception, and it doesn't let you
code without catching the exception and findout later after 2 days of
debugging it was that damned Exception all along when, if you were forced to
catch it, you would've figured it out in 3 seconds after trying to compile
your code without it.

<phew>

Anyway, long story short - throws = important and required, please include.
:)

-Brady


"Eric Gerlach" <egerlach canada.com> wrote in message
news:3B883583.1020802 canada.com...

 In anticipation of those that disagree with a semi-mandatory 'throws'
 clause, I'm going to take some arguments from a "better than C++"
 exception implementation, Java.

 One of the concerns people have with making exceptions mandatory is the
 need to then either catch every possible exception, or specify it in
 your throws declaration.  Now while this is true, it's not such a bad
 thing.  Java deals with it nicely in two ways.

 To understand the first method, read section 11.2 (including 11.2.1 and
 11.2.2) in the Java Language Speccification to be found at:



4121

 (I strongly encourage reading the entire section 11, it's not that long)

 Java allows RuntimeExceptions and Errors not to be declared in the
 throws, because those ones either are unidentifiable at compile time, or
 are serious and rare enough to bypass the decalaration rule.  All others
 must be, and I'd argue should be, based on my previous post.

 The second method is documented in Java's documentation on Throwable:

 http://java.sun.com/j2se/1.4/docs/api/java/lang/Throwable.html

 There's a bit in the middle that talks about 'chaining' of exceptions,
 which allows an exception to know what exception caused it to be thrown.
   Essentially what it allows is this (from the page):

 try {
    lowLevelOp();
 } catch LowLevelException(le) {
    throw new HighLevelException(le);  // Chaining-aware constructor
 }

 Then the code catching the HighLevelException(he) can call he.getCause()
 to get the LowLevelException.  That way, all sorts of low level network
 exceptions could be abstracted to NetworkException at a higher level
 with a chain down to the lower-level exception. Anyways, seek out that
 part and read it.  Good stuff.

 I hope this addresses some of the concers that people have had with this
 clause in previous posts.

 Cheers,

 Eric
Aug 25 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
	Well, I don't want to say anything nice about java but I would like to
re-second this.  I would like to be able to look at a function and have
a reasonable idea of the error I need to be ready to handle.
	I wouldn't against having the default behavior (when there is no throws
clause) be that it can throw anything, so only the masochists need
declare what they are doing.  I do believe that any library that wants
to be taken seriously should, by convention, declare throws clauses for
every method.  This way folks who like to try to recover or clean up can
have some idea what can go wrong.  Otherwise I don't see how you could
do anything more that say 
	"I died because " + exception.msg();

Dan

Bradeeoh wrote:

 
 I've been doing an INCREDIBLY large amount of Java programming lately, and I
 just want to say that I knew this, and because of my experience with it,
 know how invaluabl it is.  I want to second absolutely every thing you said
 in your first post and the follow up and say that, indeed, the throws clause
 is completely neccesary for real, complete contracted programming (or some
 substitution thereof) and is even fairly critical outside of contracts (ie,
 Java)
 
 Of the many reasons programming in Java can go so much quicker and smoother,
 I think the throws concept requiring Exceptions to be caught is one of them,
 because the compiler KNOWS there may be an exception, and it doesn't let you
 code without catching the exception and findout later after 2 days of
 debugging it was that damned Exception all along when, if you were forced to
 catch it, you would've figured it out in 3 seconds after trying to compile
 your code without it.
 
 <phew>
 
 Anyway, long story short - throws = important and required, please include.
 :)
 
 -Brady
 
 "Eric Gerlach" <egerlach canada.com> wrote in message
 news:3B883583.1020802 canada.com...

 In anticipation of those that disagree with a semi-mandatory 'throws'
 clause, I'm going to take some arguments from a "better than C++"
 exception implementation, Java.

 One of the concerns people have with making exceptions mandatory is the
 need to then either catch every possible exception, or specify it in
 your throws declaration.  Now while this is true, it's not such a bad
 thing.  Java deals with it nicely in two ways.

 To understand the first method, read section 11.2 (including 11.2.1 and
 11.2.2) in the Java Language Speccification to be found at:



 4121

 (I strongly encourage reading the entire section 11, it's not that long)

 Java allows RuntimeExceptions and Errors not to be declared in the
 throws, because those ones either are unidentifiable at compile time, or
 are serious and rare enough to bypass the decalaration rule.  All others
 must be, and I'd argue should be, based on my previous post.

 The second method is documented in Java's documentation on Throwable:

 http://java.sun.com/j2se/1.4/docs/api/java/lang/Throwable.html

 There's a bit in the middle that talks about 'chaining' of exceptions,
 which allows an exception to know what exception caused it to be thrown.
   Essentially what it allows is this (from the page):

 try {
    lowLevelOp();
 } catch LowLevelException(le) {
    throw new HighLevelException(le);  // Chaining-aware constructor
 }

 Then the code catching the HighLevelException(he) can call he.getCause()
 to get the LowLevelException.  That way, all sorts of low level network
 exceptions could be abstracted to NetworkException at a higher level
 with a chain down to the lower-level exception. Anyways, seek out that
 part and read it.  Good stuff.

 I hope this addresses some of the concers that people have had with this
 clause in previous posts.

 Cheers,

 Eric
Aug 26 2001
parent reply Eric Gerlach <egerlach canada.com> writes:
  Well, I don't want to say anything nice about java but I would like to
 re-second this.  I would like to be able to look at a function and have
 a reasonable idea of the error I need to be ready to handle.


I don't usually advocate Java either... I'm only half-pleased with their 
VM way of doing things, and am still not sure about the class library, 
it's complete, but as someonw mentioned, if you use one bit, you have to 
use all the bits.  However, IMHO exception handling is one thing they 
got right.


 	I wouldn't against having the default behavior (when there is no throws
 clause) be that it can throw anything, so only the masochists need
 declare what they are doing.  I do believe that any library that wants
 to be taken seriously should, by convention, declare throws clauses for
 every method.  This way folks who like to try to recover or clean up can
 have some idea what can go wrong.  Otherwise I don't see how you could
 do anything more that say 
 	"I died because " + exception.msg();


Six months ago I would have been okay with it too, but working on the 
most recent project I've been working on, I can't say I'm okay with it 
anymore.  The project was built in C++ through a series of grafts, and 
eventually emerged as a complete system.

One of the annoying problems we've been having is that occasionally 
someone forgets to document an exception in a header file.  The 
exceptional case occurs, and it throws.  That exception propagates 
half-way up the call stack, and is caught in a really wierd place.  Our 
exceptions don't know where they came from in code (another problem), 
and so you spend a while trying to figure out what part of your code 
threw that exception, and it ends up being annoying.

There are three ways to handle a mandatory throws clause:
1) Don't throw exceptions :)
2) Document every specific exception that could be thrown (the Good Way) or
3) 'throws (Exception)' (the 'I'm Lazy') way.

So, there is a way to get around a mandatory throws clause if you don't 
want to document every exception.  At least that way people who call 
your function know you might throw *something*, but it won't be very 
meaningful.  But, the whole point of meaningful exceptions is so that 
you can recover gracefully from them.  Otherwise, you're right, all you 
get is:

"I died because " + exception.msg();

Ow.  I don't want my app doing that.

Eric

P.S. Idea: Exceptions should know what file and line they were thrown 
from by default.**
Aug 26 2001
parent "Sean L. Palmer" <spalmer iname.com> writes:
 P.S. Idea: Exceptions should know what file and line they were thrown
 from by default.**


Yes.
Nov 03 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Here's my problem with a throws clause:

A calls B
B calls C
C calls D

D is in some third party library. Now, D is updated to throw another
exception. Now, the code in C, B, and A all needs to be updated. To me, this
breaks code reuse.

-Walter
Aug 26 2001
next sibling parent reply Eric Gerlach <egerlach canada.com> writes:
Walter wrote:

 Here's my problem with a throws clause:
 
 A calls B
 B calls C
 C calls D
 
 D is in some third party library. Now, D is updated to throw another
 exception. Now, the code in C, B, and A all needs to be updated. To me, this
 breaks code reuse.
 
 -Walter


If you think about it, either way it breaks code reuse.  In fact, 
changing *any* part of a contract breaks code reuse!  If D changes his 
pre- or post-conditions, C is going to run into problems, because the 
'assert(i<=5)' just became 'assert(i<5)', and he's counting on passing 
5s!  That isn't any reason to not include them in the language (as the 
language D so aptly demonstrates).

Back to exceptions:  If D adds a new exception, C, B, and A are broken 
anyways, because they don't know it's coming!  I think having the clause 
breaks code reuse *less*, not more.

Consider a stack of fixed size which used to perform a no-op if you 
tried to push beyond the limits of the stack.  Well, the author decided 
that it wasn't good behaviour for the stack, and so now the push() 
method throws an exception.  The stack is D.

The author of C downloads the new version of D to run his unit tests 
(yay for unit tests) to make sure his still works.  Now, one of several 
things happen based on whether there is a mandatory throws clause or not.

Mandatory throws clause:  C's code doesn't compile.  "Damn," he says, 
and adds the five or so lines of code to catch and chain the exception. 
  If he's not sure how to handle it, he has to think about it.

No throws clause:  Turns out C's unit tests weren't quite thorough, and 
he missed the boundary case where the exception would be thrown (C isn't 
a simple system).

I'm the author of A.

If there is a mandatory throws clause, I probably don't even notice that 
a new exception is there.  A good programmer at the C or B level will 
catch and *handle* the exception as it should be handled.  So with a 
throws clause I'm less likely to be affected at all.  If I am affected, 
it will be that my code doesn't compile.  No problem.  I add a few lines 
and go merrily on my way.

That is certainly preferable to the alternative, which occurs without a 
throws clause.  I find out four months after deployment of my new 
software that the stupid author of D added an exception to his code 
which bubbled up to my code.  Now I have to issue a patch and change all 
my code... But wait!  I can't even catch the specific exception, because 
it's not in my scope!  In fact, even if I catch a generic Exception, I 
can't handle it properly, because I have no idea what the innards of B, 
C, or D are!  Even worse, I don't even know that it is D that is causing 
me problems!!!  There is no way to fix this problem, except to contact 
the author of B, who after hours of searching finds the obscure case and 
contacts the author of C, who does the same and eventually the author of 
D is contacted who tells us all: "Oh yeah, I added an exception."

What pisses me off more?  Having to add three lines to catch a new 
exception from B because my code won't compile? (Which likely wouldn't 
happen) OR the horrible scenario I described in the last paragraph?  I'd 
say I'd rather recompile than face that crap.

My code is less *critially* broken if the throws clause is there, and 
mandatory.

Now I can understand your reluctance to add it to the language if there 
is a good *compiler* reason to leave it out.  But I think from a 
language architecture standpoint it's a good idea.

Cheers,

Eric
Aug 26 2001
parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Eric Gerlach wrote:

 
 Walter wrote:

 Here's my problem with a throws clause:

 A calls B
 B calls C
 C calls D

 D is in some third party library. Now, D is updated to throw another
 exception. Now, the code in C, B, and A all needs to be updated. To me, this
 breaks code reuse.

 -Walter


 
 If you think about it, either way it breaks code reuse [...snippy...]


Eric, thanks for your excellent example here. I'd been leaning 
against throws-contracting out of laziness, and your argument is 
persuasive.

(Hey, what are the interactions between C++ exceptions and
D exceptions? Does propagation always stop at the language 
barrier?)

I'd personally like to write code for quick-n-dirty tools without
being concerned with exceptions at all. Can we define some solution
wherein the default behavior is to not care what exceptions might 
be thrown?

-RB
Aug 26 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Russell Bornschlegel wrote in message <3B89ECDD.1282D39D estarcion.com>...

(Hey, what are the interactions between C++ exceptions and
D exceptions? Does propagation always stop at the language
barrier?)



Since, in C++, you can throw any type, but in D, you can only throw class
instances of a type that doesn't exist in C++, there's an obvious
compatibility problem. One solution is to fake a wrapper around any incoming
C++ exception, but I feel a better solution is to ignore the problem and
assert that exceptions should not propagate across DLL or language
boundaries.



I'd personally like to write code for quick-n-dirty tools without
being concerned with exceptions at all. Can we define some solution
wherein the default behavior is to not care what exceptions might
be thrown?



That might be best.
Aug 27 2001
parent "Sean L. Palmer" <spalmer iname.com> writes:
I'd personally like to write code for quick-n-dirty tools without
being concerned with exceptions at all. Can we define some solution
wherein the default behavior is to not care what exceptions might
be thrown?



 That might be best.


Perhaps if the compiler detects exceptions that aren't handled, it might
issue a warning... if you're just doing something quick and dirty, you could
feel free to ignore this warning.

I'm all in favor of forcing code to be more robust and reliable.  So I guess
I'm in favor of explicit throws() clauses, unless the compiler can detect
this for me.

Sean
Nov 03 2001
prev sibling parent reply Eric Gerlach <egerlach canada.com> writes:
 Eric, thanks for your excellent example here. I'd been leaning 
 against throws-contracting out of laziness, and your argument is 
 persuasive.


I try.  :)


 I'd personally like to write code for quick-n-dirty tools without
 being concerned with exceptions at all.


The thing is, the language uses exceptions as its method of 
communicating errors.  So no matter what you do, you're going to have 
exceptions to think about.

If there were a mandatory 'throws' clause you could just have every 
function 'throws (Exception)' and you're fine.  That is a bit ugly 
though. :(


 Can we define some solution
 wherein the default behavior is to not care what exceptions might 
 be thrown?


I'm not sure exactly what you mean by this.  If you're referring to Dan 
Hursh's idea:


       void f() throws();		// I throw nothing
 	void g() throws(X, Y, Z)	// I throw X, Y & Z type exceptions
 	void h();			// I'm making no promises


Then that's what I'd call the minimum.  What I glean from this is that 
if a function declaration has a 'throws' clause, then the compiler will 
check the body of that function to make sure that no other exceptions 
other than those declared could possibly be thrown.  If there is no 
throws clause, there is no contract there.

To be honest, that's not a bad solution when compared to the other 
contract mechanisms.  Just as you are encouraged to use in, out, 
invariant and test blocks for your code, you'd be encouraged to use 
throws clauses too.

One suggestion though:  I think compiler warnings should be issued if 
there is the threat of exceptions being thrown in a function that 
doesn't have a throws clause.  So the enforcement comes when you have 
warnings-as-errors and -Wall on, as many good applications do.

Now, here's a challenge: design a language that *ennforces* the proper 
use of pre- and post- conditions, as well as class invariants.  Damn 
that'd be neat.

Eric
Aug 27 2001
next sibling parent Dan Hursh <hursh infonet.isl.net> writes:
Eric Gerlach wrote:

 Now, here's a challenge: design a language that *ennforces* the proper
 use of pre- and post- conditions, as well as class invariants.  Damn
 that'd be neat.
 
 Eric


	That's scary.  Do you mean it would make sure they are meaningful?  If
the compiler could do that, it wouldn't be to far away from writing your
code for you.  
	It reminds me of a feeble attempt a group at the university I went to
tried.  They wanted to design a language that would allow the programmer
to define, in mathematics notion, what a piece of code was supposed to
do using pre & post conditions, requires & returns clauses, assume &
invariant statements and the like for each routine, function, module and
loop.  The compiler has to understand graph theory and turning theory. 
It amounted to the programmer writing the code once as an interface
description and again as real code.  The idea being that you could swap
implementation as long as the compiler agreed that it still fit the
mathematic interface description.
	They tried to graft this monstrosity onto C++ (it was the only way they
would switch from teaching Modula-2) and taught it to a few years of
students who thought they were being taught straight C++.  I was pretty
decent a C++ at the time, but I could not read the code at all.  They
made up dozens of new keywords that just didn't fit.  The library was
made so the students had to have 10-20 MB of quota to compile the most
trivial of programs.  The compiler required all of those contract
declarations but I don't think they ever amounted to being anything more
that required comments.  The compiler logic was too complicated to
actually use them for validity checking.
	I've heard rumors that they were going to try grafting this thing on
scheme and java.  I believe the C++ implementation was considered a
loss.  
	Getting back to you suggestion, it's not that the idea isn't neat and
the intentions I'm sure are good, but it gives me flashbacks.  A Prof.'s
research should never be taught as a standard before it has been proven
(or falls on it's face).

Dan
Aug 27 2001
prev sibling next sibling parent reply Chris Friesen <chris_friesen sympatico.ca> writes:
Eric Gerlach wrote:


 Then that's what I'd call the minimum.  What I glean from this is that
 if a function declaration has a 'throws' clause, then the compiler will
 check the body of that function to make sure that no other exceptions
 other than those declared could possibly be thrown.  If there is no
 throws clause, there is no contract there.


So then the compiler has to construct some kind of lookup table as to what
exceptions each function with a 'throws' clause in the entire system (including
all the libraries that you use) can throw.  In a large system I could imagine
this taking a LOT of memory to keep track of.

I'm all for it, but it's going to cost us.

Chris
Aug 27 2001
parent reply Eric Gerlach <egerlach canada.com> writes:
 So then the compiler has to construct some kind of lookup table as to what
 exceptions each function with a 'throws' clause in the entire system (including
 all the libraries that you use) can throw.  In a large system I could imagine
 this taking a LOT of memory to keep track of.


I'm not sure that's true.  As I'm going over the parse tree, when in a 
function that has a throws clause I check to see if it has any function 
calls inside which have throws clauses themselves.  If I find one, and 
it isn't caught or declared in that scope, I print out an error and die. 
  If there's anything to keep track of, it's no bigger than parameter 
declarations anyways.

The record of 'who throws what' shouldn't have to carry over to runtime, 
as it will have already been checked and verified.  Of course, that is 
only the case if we can't speed up execution by having it.

Eric
Aug 27 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
Eric Gerlach wrote:

 

 So then the compiler has to construct some kind of lookup table as to what
 exceptions each function with a 'throws' clause in the entire system (including
 all the libraries that you use) can throw.  In a large system I could imagine
 this taking a LOT of memory to keep track of.


 
 I'm not sure that's true.  As I'm going over the parse tree, when in a
 function that has a throws clause I check to see if it has any function
 calls inside which have throws clauses themselves.  If I find one, and
 it isn't caught or declared in that scope, I print out an error and die.
   If there's anything to keep track of, it's no bigger than parameter
 declarations anyways.
 
 The record of 'who throws what' shouldn't have to carry over to runtime,
 as it will have already been checked and verified.  Of course, that is
 only the case if we can't speed up execution by having it.
 
 Eric


	Actually, when in a function with a throws clause, you have to check
all the functions, even the once without a throws clause.  You are
making a promise even if the functions you call don't.  Basically I
would assume a function without a throws clause is implying he throws
the exception base class.
	On a related note, how will this affect virtual method calls?  Does
this mean that if you override a method you can only have a throws
clause containing the same types as your base class or your exceptions
have to be subclasses of the exceptions you parent throws?  I would
assume so, but is this reasonable in practice?  Do throws clauses get
attached to interface signatures?  Again, I think so and I do know if
this is reasonable.  It sounds like it would require though on the
behave of interface and class designers so that they don't paint folks
into a corner.
	BTW. I'm still in favor of having throws clauses and enforcing them.

Dan
Aug 27 2001
parent Eric Gerlach <egerlach canada.com> writes:
 Actually, when in a function with a throws clause, you have to check
 all the functions, even the once without a throws clause.  You are
 making a promise even if the functions you call don't.  Basically I
 would assume a function without a throws clause is implying he throws
 the exception base class.


Well, if *all* the functions had mandatory throws clauses that wouldn't 
be a problem now would it? :))

I never did think of that though.  OTOH, it couldn't be that big could 
it?  I mean, all of the function's parameters have to be kept in a table 
somewhere... would exceptions take that much more room?


 	On a related note, how will this affect virtual method calls?  Does
 this mean that if you override a method you can only have a throws
 clause containing the same types as your base class or your exceptions
 have to be subclasses of the exceptions you parent throws?  I would
 assume so, but is this reasonable in practice?  Do throws clauses get
 attached to interface signatures?  Again, I think so and I do know if
 this is reasonable.  It sounds like it would require though on the
 behave of interface and class designers so that they don't paint folks
 into a corner.


To be honest, I was thinking about this and I couldn't figure it out 
either.  So I just went and checked what Java does:

"A method that overrides or hides another method (§8.4.6), including 
methods that implement abstract methods defined in interfaces, may not 
be declared to throw more checked exceptions than the overridden or 
hidden method.

More precisely, suppose that B is a class or interface, and A is a 
superclass or superinterface of B, and a method declaration n in B 
overrides or hides a method declaration m in A. If n has a throws clause 
that mentions any checked exception types, then m must have a throws 
clause, and for every checked exception type listed in the throws clause 
of n, that same exception class or one of its superclasses must occur in 
the throws clause of m; otherwise, a compile-time error occurs."

So it would seem that your conception isn't ludicrous.  I think that it 
makes sense, because you have to maintain the guarantee that users of 
the superclass expect.  If the body of your function (in the subclass) 
could throw another exception, well, good coding practice would dictate 
you should be handling that internally, rather than breaking the 
contract set out by your parent.

Eric
Aug 28 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Eric Gerlach wrote in message <3B8AE63F.4010400 canada.com>...

One suggestion though:  I think compiler warnings should be issued if
there is the threat of exceptions being thrown in a function that
doesn't have a throws clause.  So the enforcement comes when you have
warnings-as-errors and -Wall on, as many good applications do.



One thing I haven't mentioned in the docs, but is a design goal, is to not
have warnings. Code should compile or it should fail with a diagnostice
message. I dislike getting a piece of code from somewhere, running the
makefile, and getting a bunch of warnings. Was I compiling the code right?
Are those warnings real bugs or not? Why did whoever wrote the code ignore
the warnings? Etc. If you examine the warnings C compilers give, it is
usually to make up for some weakness in the language. I've tried to address
those weaknesses, and thereby getting rid of the warnings.


Now, here's a challenge: design a language that *ennforces* the proper
use of pre- and post- conditions, as well as class invariants.  Damn
that'd be neat.



But I still want to be able to just bang out sloppy code for a one-shot
purpose. Some programming jobs are worth doing but not worth doing well <g>.
Aug 28 2001
parent reply Eric Gerlach <egerlach canada.com> writes:
 Eric Gerlach wrote in message <3B8AE63F.4010400 canada.com>...
 

One suggestion though:  I think compiler warnings should be issued if
there is the threat of exceptions being thrown in a function that
doesn't have a throws clause.  So the enforcement comes when you have
warnings-as-errors and -Wall on, as many good applications do.


 One thing I haven't mentioned in the docs, but is a design goal, is to not
 have warnings. Code should compile or it should fail with a diagnostice
 message. I dislike getting a piece of code from somewhere, running the
 makefile, and getting a bunch of warnings. Was I compiling the code right?
 Are those warnings real bugs or not? Why did whoever wrote the code ignore
 the warnings? Etc. If you examine the warnings C compilers give, it is
 usually to make up for some weakness in the language. I've tried to address
 those weaknesses, and thereby getting rid of the warnings.


I thought that might be the case due to how you deal with what used to 
be local variable warnings.  Well, if that's your reasoning for removing 
compiler warnings, I think the throws clause should be mandatory.

Essentially, if you're making all warnings errors by default, you're 
trying to have the language clean up people's sloppy code.  I think this 
is a Good Thing.  However, not bothering to declare exceptions is sloppy 
code.  People should be at least warned if their functions might throw 
an exception.  Heck, I'd like to be.

When I was doing programming competitions a few years back, we'd have a 
Pascal file that started with:

var
   a, b, c, i, j, k, l, m, n, q, x, y, z : Integer;

The reason was we didn't want to spend time thinking about variable 
definitions.  It's sloppy, yes, but we just wanted to bang out some code 
quickly.  In C, this would have caused warnings.  In D, this would cause 
an error.

D can't let people get away with being sloppy in some areas but not in 
others.  If D is going to crack down on sloppy code from programmers, 
then it should be as ruthless with exceptions as it is about all other 
aritifacts of sloppy code.

Now, the argument has been made:  "Sometimes I want to bang out code 
quick without regard to exceptions."  Well, how about without regard to 
local variables?  Signed/unsigned comparisons? (which I assume will 
become an error as well... as it is typically a warning)  All these 
things are marks of sloppy coding.  If they're warnings, then you get 
the problems described above by Walter.  If they're errors, you can't 
bang out quick code.

Perhaps what the compiler needs is to make a category of errors known as 
'non-fatal' errors.  i.e. If you have one your code will still run, but 
it may not run well.  Then, add a '-sloppy' or like switch to the 
compiler, which lets it behave leniantly with regard to these errors.

Now you have the tight checking for production-level code, and you have 
the leniant mode to allow for quick, dirty work.  Not to mention, you 
have to explicitly invoke the sloppy mode, so the majority of code will 
be clean.  Personally, I think that solution works great.  Gives 
flexibility of C when you need it, but is usually very strict like Java. 
  The best of both worlds!

Now, here's a challenge: design a language that *ennforces* the proper
use of pre- and post- conditions, as well as class invariants.  Damn
that'd be neat.


 
 But I still want to be able to just bang out sloppy code for a one-shot
 purpose. Some programming jobs are worth doing but not worth doing well <g>.


Oh goodness!  I didn't mean *do* it.... I just meant it would be a 
challenge.  Any takers? :)
Aug 28 2001
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Eric Gerlach wrote in message <3B8C30BB.2060805 canada.com>...

Now, the argument has been made:  "Sometimes I want to bang out code
quick without regard to exceptions."  Well, how about without regard to
local variables?  Signed/unsigned comparisons? (which I assume will
become an error as well... as it is typically a warning)  All these
things are marks of sloppy coding.  If they're warnings, then you get
the problems described above by Walter.  If they're errors, you can't
bang out quick code.



Oh, so you want me to be consistent? <g> <harrumph>


Perhaps what the compiler needs is to make a category of errors known as
'non-fatal' errors.  i.e. If you have one your code will still run, but
it may not run well.  Then, add a '-sloppy' or like switch to the
compiler, which lets it behave leniantly with regard to these errors.



Every compiler switch is a bug.
Aug 28 2001
next sibling parent reply Eric Gerlach <egerlach canada.com> writes:
 Eric Gerlach wrote in message <3B8C30BB.2060805 canada.com>...
 

Now, the argument has been made:  "Sometimes I want to bang out code
quick without regard to exceptions."  Well, how about without regard to
local variables?  Signed/unsigned comparisons? (which I assume will
become an error as well... as it is typically a warning)  All these
things are marks of sloppy coding.  If they're warnings, then you get
the problems described above by Walter.  If they're errors, you can't
bang out quick code.


 Oh, so you want me to be consistent? <g> <harrumph>


eep! 
OfcourseI'mnotpresumingtoimposeonyouinanymannerwhatsoeverIsimplybelievethattheconceptsa
emutuallyexclusive. 

Pleasedon'tkillmeohgreatlanguagedesignersir.

:)


Perhaps what the compiler needs is to make a category of errors known as
'non-fatal' errors.  i.e. If you have one your code will still run, but
it may not run well.  Then, add a '-sloppy' or like switch to the
compiler, which lets it behave leniantly with regard to these errors.


 Every compiler switch is a bug.


I think that's over-generalisation.  For example, you've described 
several compiler switches.  Are they bugs?  There are some decisions 
that have to be made at the compiler level, and not at the code level. 
One such example is whether to generated debug symbols or not, another 
is code optimisation.  You have to have compiler switches for those.

I think that relaxing the errors that are only there for code-style 
enforcement should be another one.  There are obviously two ways of 
writing code: the strict way, and the loose way.  I think that D tends 
towards the strict way, so make it go all the way by default, and allow 
programmers to loosen it up if they want.  Really, it doesn't matter 
how, I just thought a compiler switch was appropriate.

Eric
Aug 29 2001
parent "Walter" <walter digitalmars.com> writes:
Eric Gerlach wrote in message <3B8D8D13.4090609 canada.com>...

Perhaps what the compiler needs is to make a category of errors known as
'non-fatal' errors.  i.e. If you have one your code will still run, but
it may not run well.  Then, add a '-sloppy' or like switch to the
compiler, which lets it behave leniantly with regard to these errors.


 Every compiler switch is a bug.


I think that's over-generalisation.  For example, you've described
several compiler switches.  Are they bugs?  There are some decisions
that have to be made at the compiler level, and not at the code level.
One such example is whether to generated debug symbols or not, another
is code optimisation.  You have to have compiler switches for those.



Yes, of course. I was referring to the idea that compiling a program should
be as simple as running the compiler. You shouldn't have to consult a thick
manual to figure out the plethora of switches. Look at C/C++ programming.
Ever see a makefile without a looong list of switches that change the
language being compiled, add layers of explicit and implicit #define's,
etc.?



I think that relaxing the errors that are only there for code-style
enforcement should be another one.  There are obviously two ways of
writing code: the strict way, and the loose way.  I think that D tends
towards the strict way, so make it go all the way by default, and allow
programmers to loosen it up if they want.  Really, it doesn't matter
how, I just thought a compiler switch was appropriate.



One issue with this idea is having multiple incompatible builds of, say, a
library.
Sep 01 2001
prev sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
Walter wrote:

 Every compiler switch is a bug.


	Especially that '-o' one.  If it ain't called a.out, I ain't runnin'
it!

:-)
Aug 29 2001
parent reply "Walter" <walter digitalmars.com> writes:
Dan Hursh wrote in message <3B8DAED3.630B4D97 infonet.isl.net>...

Walter wrote:

 Every compiler switch is a bug.


 Especially that '-o' one.  If it ain't called a.out, I ain't runnin'
it!

:-)


-o is a bug. After all, the compiler should be smart enough to figure out
that if you compile foo.c, the resulting executable should be named foo (or
foo.exe for win32).
Sep 01 2001
parent "Angus Graham" <agraham_d agraham.ca> writes:
"Walter" <walter digitalmars.com> wrote:


 -o is a bug. After all, the compiler should be smart enough to figure out
 that if you compile foo.c, the resulting executable should be named foo


(or

 foo.exe for win32).


So make sure not to call any files win.c!  :-)

"Hello tech support?  When I turn on my computer it only says 'Hello
World!'"


Angus
Sep 02 2001
prev sibling parent "John Carney" <john.carney pacific.net.au> writes:
<snip>


 Now, the argument has been made:  "Sometimes I want to bang out code
 quick without regard to exceptions."  Well, how about without regard to
 local variables?  Signed/unsigned comparisons? (which I assume will


Type safety? Encapsulation? The list goes on...
Aug 29 2001
prev sibling next sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
Walter wrote:

 
 Here's my problem with a throws clause:
 
 A calls B
 B calls C
 C calls D
 
 D is in some third party library. Now, D is updated to throw another
 exception. Now, the code in C, B, and A all needs to be updated. To me, this
 breaks code reuse.
 
 -Walter


	You are right, but I consider it a side affect of the interface of D
changing.  I be upset if the number or types of parameter to D changed
and the compiler didn't flag that.  Throwing a new type of exception is
like changing the type of a parameter.  One of my big problems with
errno is that platforms can make up their own values.  They can change
them add them remove and I would never know and hence I cannot even
attempt to handle in any way except to ignore them or throw my hands up
and abort.
	So you right, it a pain, but it's D's fault for changing the API. 
Error conditions should be a part of a good API.  If A want's he can be
lazy and just have a throws clause of Exception or what ever the
exception base class is.  You could also pick up the syntax:

	void f() throws();		// I throw nothing
	void g() throws(X, Y, Z)	// I throw X, Y & Z type exceptions
	void h();			// I'm making no promises

I think libraries should document their errors with throws clauses, but
I wouldn't want the language to enforce that.  

Dan
Aug 26 2001
parent reply "John Carney" <john.carney pacific.net.au> writes:
<snip>


 You are right, but I consider it a side affect of the interface of D
 changing.  I be upset if the number or types of parameter to D changed
 and the compiler didn't flag that.  Throwing a new type of exception is
 like changing the type of a parameter.  One of my big problems with
 errno is that platforms can make up their own values.  They can change
 them add them remove and I would never know and hence I cannot even
 attempt to handle in any way except to ignore them or throw my hands up
 and abort.
 So you right, it a pain, but it's D's fault for changing the API.
 Error conditions should be a part of a good API.  If A want's he can be
 lazy and just have a throws clause of Exception or what ever the


Amen.


 exception base class is.  You could also pick up the syntax:

 void f() throws(); // I throw nothing
 void g() throws(X, Y, Z) // I throw X, Y & Z type exceptions
 void h(); // I'm making no promises


I'd much rather require that a method without an exception contract state it
explicitly:

    void f() ;    // I throw nothing
    void g() throws (X, Y, Z) ; // I throw X, Y & Z
    void h() throws anything ; // Warning! Warning! Lazy programmer ;-)


 I think libraries should document their errors with throws clauses, but
 I wouldn't want the language to enforce that.


Can I ask a question of everybody on this thread? How many of you have
actually spent anytime working with a language that has rigorous exception
specification syntax (eg. Java)? I spent 18 months programming almost
exclusively in Java and I honestly did not find having to declare exceptions
a bother. As for API drift being a problem in this regard, it happens a hell
of a lot less than you might imagine - and when it does happen, you can
relax in the certain knowledge that you're compiler's going to tell you
about each and every point at which changes in a 3rd party library has
broken your code.

Regards,
John Carney.
Aug 28 2001
next sibling parent reply Dan Hursh <hursh infonet.isl.net> writes:
John Carney wrote:

 exception base class is.  You could also pick up the syntax:

 void f() throws(); // I throw nothing
 void g() throws(X, Y, Z) // I throw X, Y & Z type exceptions
 void h(); // I'm making no promises


 
 I'd much rather require that a method without an exception contract state it
 explicitly:
 
     void f() ;    // I throw nothing
     void g() throws (X, Y, Z) ; // I throw X, Y & Z
     void h() throws anything ; // Warning! Warning! Lazy programmer ;-)


	But this seems to defeat the lazy programer's purpose.  He's LAZY.  He
doesn't want to have to declare that he's not declaring something.  That
one of the things I find amusingly correct about perl's requirement that
programmer who want to be forced to declare variables, have to declare
that they want to have to declare variables.  The lazy programmer does
nothing and gets the behavior that benefits lazy programmers.  It's
poetic in nature.


 I think libraries should document their errors with throws clauses, but
 I wouldn't want the language to enforce that.


 
 Can I ask a question of everybody on this thread? How many of you have
 actually spent anytime working with a language that has rigorous exception
 specification syntax (eg. Java)? I spent 18 months programming almost
 exclusively in Java and I honestly did not find having to declare exceptions
 a bother. 


Java is a VM.  There's a difference.


 As for API drift being a problem in this regard, it happens a hell
 of a lot less than you might imagine - and when it does happen, you can
 relax in the certain knowledge that you're compiler's going to tell you
 about each and every point at which changes in a 3rd party library has
 broken your code.


	API drift may not happen much, but platform differences are another
matter.  That's one reason why errno can be ugly.  With some many
standard to choose from, which ones do you pick and how closely do you
stick to each one.  Vendors like to deviate from specs in order to
accentuate their advantages in cases where specs try to pick least
common denominators.  Different implementation allow for different error
conditions.
	With Java you have one platform, the JVM, and it is only liable to
change every six months or however often Sun decides to mess with the
world.  When compiling to something less standard, say native operation
systems, you have room for a lot more differences.  This would have a
bad gut feeling to anyone who has had to deal with portability a lot. 
You now have API drift for several different platforms, and they don't
even happen at the same time.
	Now, I still agree that throws clauses should be in.  It will be easier
for API designer's to declare IN BLOOD the classes of errors that the
developer should have to worry about.  Provided that the API developers
exercise on ounce of forethought, it should be possible to provide a
setup of exception classes that covers the least common denominators,
with giving platform vendors the ability to provide platform specific
subclasses for better error granularity for those you want to tie
themselves to a single platform or like to use conditional compilation.
	Provided that you give in to letting lazy tools programmer not declare
any throws clause and get the lazy behavior of passing on all
exceptions, they should have nothing to complain about.  It will only
impact implementors of compilers and libraries.  I guess anyone writing
a code analyzer might care too.

Dan
Aug 28 2001
parent reply "John Carney" <john.carney pacific.net.au> writes:
"Dan Hursh" <hursh infonet.isl.net> wrote in message
news:3B8C760E.72C63D32 infonet.isl.net...

 John Carney wrote:

 exception base class is.  You could also pick up the syntax:

 void f() throws(); // I throw nothing
 void g() throws(X, Y, Z) // I throw X, Y & Z type exceptions
 void h(); // I'm making no promises


 I'd much rather require that a method without an exception contract




state it

 explicitly:

     void f() ;    // I throw nothing
     void g() throws (X, Y, Z) ; // I throw X, Y & Z
     void h() throws anything ; // Warning! Warning! Lazy programmer ;-)


 But this seems to defeat the lazy programer's purpose.  He's LAZY.  He
 doesn't want to have to declare that he's not declaring something.  That
 one of the things I find amusingly correct about perl's requirement that
 programmer who want to be forced to declare variables, have to declare
 that they want to have to declare variables.  The lazy programmer does
 nothing and gets the behavior that benefits lazy programmers.  It's
 poetic in nature.


<sigh>

The problem is that lazy programming becomes the de facto standard - you
might as well not bother with a throws clause in the first place. Why go to
all the trouble of declaring throws in your library if your clients are not
going to get any benefit from it? This is the argument that Walter clearly
favours because there is no throws clause in the language. I agree with him
in this respect - if you're not going to have strict exception
specification, then you might as well not have any.


 I think libraries should document their errors with throws clauses,






but

 I wouldn't want the language to enforce that.


 Can I ask a question of everybody on this thread? How many of you have
 actually spent anytime working with a language that has rigorous




exception

 specification syntax (eg. Java)? I spent 18 months programming almost
 exclusively in Java and I honestly did not find having to declare




exceptions

 a bother.


 Java is a VM.  There's a difference.


Ummmm. And why does that make a strict throws clause any easier for the
programmer?


 As for API drift being a problem in this regard, it happens a hell
 of a lot less than you might imagine - and when it does happen, you can
 relax in the certain knowledge that you're compiler's going to tell you
 about each and every point at which changes in a 3rd party library has
 broken your code.


 API drift may not happen much, but platform differences are another
 matter.  That's one reason why errno can be ugly.  With some many
 standard to choose from, which ones do you pick and how closely do you
 stick to each one.  Vendors like to deviate from specs in order to
 accentuate their advantages in cases where specs try to pick least
 common denominators.  Different implementation allow for different error
 conditions.
 With Java you have one platform, the JVM, and it is only liable to
 change every six months or however often Sun decides to mess with the
 world.  When compiling to something less standard, say native operation
 systems, you have room for a lot more differences.  This would have a
 bad gut feeling to anyone who has had to deal with portability a lot.
 You now have API drift for several different platforms, and they don't
 even happen at the same time.



And underneath the VM there is a whole host of different platforms each with
their own error conditions which don't stop ocurring just because you've
pasted a VM over the top of it all - and they all have to get reported one
way or another. The fact is that most error conditions *aren't* platform
specific - they may be reported in different ways, but an out of memory
error is an still an out of memory error whether you're running Windows,
Solaris, Irix, Linux, FreeBSD, BeOS, PalmOS, VMS, TRS-DOS or AppleSoft.

Regards,
John Carney.
Aug 29 2001
next sibling parent Dan Hursh <hursh infonet.isl.net> writes:
John Carney wrote:

 The problem is that lazy programming becomes the de facto standard - you
 might as well not bother with a throws clause in the first place. Why go to
 all the trouble of declaring throws in your library if your clients are not
 going to get any benefit from it? This is the argument that Walter clearly
 favours because there is no throws clause in the language. I agree with him
 in this respect - if you're not going to have strict exception
 specification, then you might as well not have any.


	In that case, let me make Walter's case stronger for him.  What good
are strict exceptions clauses when everyone uses "throws(exception)"? 
You'll have that problem either way.  At let's the quick tool's writer's
will like you better if the lack of the clause gives them that behavior.
	For what it's worth, I would probably use them in most of my code
because I'm anal.  Where I work we tend to use them all the time in Java
except for those things that are needed quick (as in yesterday) as a
patch until we can get a real fix put together.  In those cases
everything throws "exception".  I think it is a bit hasty to say no one
would use the if given the choice.  It sounds like you would.  I would. 
I would berate any API designer who puts out a library for public
without throws clauses (assuming we don't talk Walter out of them).


 Java is a VM.  There's a difference.


 
 Ummmm. And why does that make a strict throws clause any easier for the
 programmer?


	Vendors can make too many changes to the sun API.  You are less of a
victim of change.  (At least that what sun tells us.)  The sun API
defines who can throw what.  Period.  It's not unreasonable to think
that native code would be more subservient to a given platform's
idiosyncrasies, including how things can fail.
	Every time any one of the vendors, who's platform you support, decides
to make a change your code could be made uncompilable.  The world gets a
lot ruder.  It's a legitimate concern that should be addressed.  I tried
to address that later on in the response.
 

 As for API drift being a problem in this regard, it happens a hell
 of a lot less than you might imagine - and when it does happen, you can
 relax in the certain knowledge that you're compiler's going to tell you
 about each and every point at which changes in a 3rd party library has
 broken your code.


 API drift may not happen much, but platform differences are another
 matter.  That's one reason why errno can be ugly.  With some many
 standard to choose from, which ones do you pick and how closely do you
 stick to each one.  Vendors like to deviate from specs in order to
 accentuate their advantages in cases where specs try to pick least
 common denominators.  Different implementation allow for different error
 conditions.
 With Java you have one platform, the JVM, and it is only liable to
 change every six months or however often Sun decides to mess with the
 world.  When compiling to something less standard, say native operation
 systems, you have room for a lot more differences.  This would have a
 bad gut feeling to anyone who has had to deal with portability a lot.
 You now have API drift for several different platforms, and they don't
 even happen at the same time.


 
 And underneath the VM there is a whole host of different platforms each with
 their own error conditions which don't stop ocurring just because you've
 pasted a VM over the top of it all - and they all have to get reported one
 way or another. 


	But Java got away with it because they provided the pretty picture that
you would be  insulted from all that.  Java tries to make every thing
look the same, and that is an easier task to do in a VM than on bare
hardware.  D is targeting bare hardware.  


 The fact is that most error conditions *aren't* platform
 specific - they may be reported in different ways, but an out of memory
 error is an still an out of memory error whether you're running Windows,
 Solaris, Irix, Linux, FreeBSD, BeOS, PalmOS, VMS, TRS-DOS or AppleSoft.


	Right, and so is a "File Not Found", or a "No More Processes" messages
(those happen often in Windows, right?) or "Disk Quota Exceeded"?  You
are right, things can go wrong all over the place even in Java.  It's
just easier to anticipate the pain it will cause when you run native. 
At least it is for me.  I've still convinced myself that exceptions must
be a part of the API definition of a function.  I've even convinced
myself that you are less exposed to increased granularity of error
reporting, but it did seem the opposite at first.
	In any case, I don't want to argue of whether there should be exception
specifications, because we both think there should be.  I would argue
that since a developer can say he throws the exception base class, you
might as well let him have it the easy way.  If you don't it's not like
there won't be editors that can be configured to do it for him.  By
allowing an open default, you will be helping the people need to do
quick and dirty hacks every so often.

Dan
Aug 29 2001
prev sibling parent reply "kaffiene" <kaffiene xtra.co.nz> writes:
 But this seems to defeat the lazy programer's purpose.  He's LAZY.  He
 doesn't want to have to declare that he's not declaring something.  That
 one of the things I find amusingly correct about perl's requirement that
 programmer who want to be forced to declare variables, have to declare
 that they want to have to declare variables.  The lazy programmer does
 nothing and gets the behavior that benefits lazy programmers.  It's
 poetic in nature.


 <sigh>

 The problem is that lazy programming becomes the de facto standard - you
 might as well not bother with a throws clause in the first place. Why go


to

 all the trouble of declaring throws in your library if your clients are


not

 going to get any benefit from it? This is the argument that Walter clearly
 favours because there is no throws clause in the language. I agree with


him

 in this respect - if you're not going to have strict exception
 specification, then you might as well not have any.


...I agree.  And if you're not going to have strict exception specification
then you may as well not bother with design-by-contract either.  Pre and
post conditions exist to ensure that code is as safe and consistent as can
be managed at compile time.  There's no point painstakingly defining the
contract for a method if an unforseen  exception sidesteps it all.

Peter.
Aug 30 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
kaffiene wrote:

 

 But this seems to defeat the lazy programer's purpose.  He's LAZY.  He
 doesn't want to have to declare that he's not declaring something.  That
 one of the things I find amusingly correct about perl's requirement that
 programmer who want to be forced to declare variables, have to declare
 that they want to have to declare variables.  The lazy programmer does
 nothing and gets the behavior that benefits lazy programmers.  It's
 poetic in nature.


 <sigh>

 The problem is that lazy programming becomes the de facto standard - you
 might as well not bother with a throws clause in the first place. Why go


 to

 all the trouble of declaring throws in your library if your clients are


 not

 going to get any benefit from it? This is the argument that Walter clearly
 favours because there is no throws clause in the language. I agree with


 him

 in this respect - if you're not going to have strict exception
 specification, then you might as well not have any.


 
 ...I agree.  And if you're not going to have strict exception specification
 then you may as well not bother with design-by-contract either.  Pre and
 post conditions exist to ensure that code is as safe and consistent as can
 be managed at compile time.  There's no point painstakingly defining the
 contract for a method if an unforseen  exception sidesteps it all.
 
 Peter.


	I think you are mistaking what I am saying.  Exceptions are still
enforced in my microcosm.  The programmer simply does not need to give a
throws clause.  In that case, 'throws(exception)' or what ever the
exception base class is can be assumed.  Face it.  If the programmer is
lazy or in a rush, he will probably do this anyhow.  You can't prevent
it without actually making the compiler analyze the enter program to
make sure the programmer's throws clauses are neither missing something
nor are they too general.  In that case you wouldn't need a throws
clause because the compiler would figure it out itself.  I don't believe
that is practical.

Maybe my original example should have been:

larry() throws();	  // I will throw nothing
moe() throws(X, Y, Z);    // I might throw X, Y & Z
shemp();		  // assume I could throw execption (aka anything)
curly() throws(exception);// I can throw the same things as shemp

Whether or not you make shemp illegal, you still has to deal with curly. 
nyuk nyuk nyuk

Dan
Aug 30 2001
next sibling parent reply "kaffiene" <kaffiene xtra.co.nz> writes:
"Dan Hursh" <hursh infonet.isl.net> wrote in message
news:3B8F175C.F0F03CFF infonet.isl.net...

 kaffiene wrote:

 But this seems to defeat the lazy programer's purpose.  He's LAZY.








He

 doesn't want to have to declare that he's not declaring something.








That

 one of the things I find amusingly correct about perl's requirement








that

 programmer who want to be forced to declare variables, have to








declare

 that they want to have to declare variables.  The lazy programmer








does

 nothing and gets the behavior that benefits lazy programmers.  It's
 poetic in nature.


 <sigh>

 The problem is that lazy programming becomes the de facto standard -






you

 might as well not bother with a throws clause in the first place. Why






go

 to

 all the trouble of declaring throws in your library if your clients






are

 not

 going to get any benefit from it? This is the argument that Walter






clearly

 favours because there is no throws clause in the language. I agree






with

 him

 in this respect - if you're not going to have strict exception
 specification, then you might as well not have any.


 ...I agree.  And if you're not going to have strict exception




specification

 then you may as well not bother with design-by-contract either.  Pre and
 post conditions exist to ensure that code is as safe and consistent as




can

 be managed at compile time.  There's no point painstakingly defining the
 contract for a method if an unforseen  exception sidesteps it all.

 Peter.


 I think you are mistaking what I am saying.  Exceptions are still
 enforced in my microcosm.  The programmer simply does not need to give a
 throws clause.  In that case, 'throws(exception)' or what ever the
 exception base class is can be assumed.  Face it.  If the programmer is
 lazy or in a rush, he will probably do this anyhow.  You can't prevent
 it without actually making the compiler analyze the enter program to
 make sure the programmer's throws clauses are neither missing something
 nor are they too general.  In that case you wouldn't need a throws
 clause because the compiler would figure it out itself.  I don't believe
 that is practical.


By disallowing strict exception specification you penalise carefull
programmers to appease lazy programmers.  That's simply a bad trade.

Peter.
Aug 30 2001
parent reply Dan Hursh <hursh infonet.isl.net> writes:
kaffiene wrote:

 I think you are mistaking what I am saying.  Exceptions are still
 enforced in my microcosm.  The programmer simply does not need to give a
 throws clause.  In that case, 'throws(exception)' or what ever the
 exception base class is can be assumed.  Face it.  If the programmer is
 lazy or in a rush, he will probably do this anyhow.  You can't prevent
 it without actually making the compiler analyze the enter program to
 make sure the programmer's throws clauses are neither missing something
 nor are they too general.  In that case you wouldn't need a throws
 clause because the compiler would figure it out itself.  I don't believe
 that is practical.


 
 By disallowing strict exception specification you penalise carefull
 programmers to appease lazy programmers.  That's simply a bad trade.


Given the example I had:

larry() throws();         // I will throw nothing
moe() throws(X, Y, Z);    // I might throw X, Y & Z
shemp();                  // assume I could throw exception (aka
anything)
curly() throws(exception);// I can throw the same things as shemp


Tell me this.  If we get rid of the shemp syntax, how would you deal
with curly?  Exceptions aside, any error reporting mechanism can be
abused.  Errno was grossly abused as were the various return code
standards.  That is a practical fact of life.  
	Sometimes it's not even abuse.  Sometimes you are writing a quick one
shot tool that you need now.  If there is an error you let the program
bomb, you fix it on the spot and you continue.  Where I work, it is
called fire fighting.  It is sub optimal, but we don't always have time
to wait on a carefully analyzed master piece.
	The way I see it, you can't stop the curly example.  It is a valid,
strict specification.  It is probably an over specification, but that is
not something the compiler can reasonably detect I would assume. 
Anything that would detect that, I suspect, would make other over
specifications illegal when they may be valid for future planning.  If
you can't argue on HOW to prevent the curly form of abuse, then I don't
see the problem with making it explicit with the shemp syntax.
	Since shemp would be a synonym for curly, it is no less strict that
curly.  Honestly, I think it makes the lack of a careful promise more
obvious.  I certainly don't agree with the argument that "It's bad style
so we should penalize it with the syntax".  If that is our plan then
let's replace goto with some that takes a few lines and lots of
redundancy.  Goto has been the root of far more evil than under
specifying error conditions.

Dan
Aug 30 2001
parent "kaffiene" <kaffiene xtra.co.nz> writes:
"Dan Hursh" <hursh infonet.isl.net> wrote in message
news:3B8F2EC1.32A08053 infonet.isl.net...

 kaffiene wrote:

 I think you are mistaking what I am saying.  Exceptions are still
 enforced in my microcosm.  The programmer simply does not need to give






a

 throws clause.  In that case, 'throws(exception)' or what ever the
 exception base class is can be assumed.  Face it.  If the programmer






is

 lazy or in a rush, he will probably do this anyhow.  You can't prevent
 it without actually making the compiler analyze the enter program to
 make sure the programmer's throws clauses are neither missing






something

 nor are they too general.  In that case you wouldn't need a throws
 clause because the compiler would figure it out itself.  I don't






believe

 that is practical.


 By disallowing strict exception specification you penalise carefull
 programmers to appease lazy programmers.  That's simply a bad trade.


 Given the example I had:

 larry() throws();         // I will throw nothing
 moe() throws(X, Y, Z);    // I might throw X, Y & Z
 shemp();                  // assume I could throw exception (aka
 anything)
 curly() throws(exception);// I can throw the same things as shemp


 Tell me this.  If we get rid of the shemp syntax, how would you deal
 with curly?  Exceptions aside, any error reporting mechanism can be
 abused.  Errno was grossly abused as were the various return code
 standards.  That is a practical fact of life.
 Sometimes it's not even abuse.  Sometimes you are writing a quick one
 shot tool that you need now.  If there is an error you let the program
 bomb, you fix it on the spot and you continue.  Where I work, it is
 called fire fighting.  It is sub optimal, but we don't always have time
 to wait on a carefully analyzed master piece.
 The way I see it, you can't stop the curly example.  It is a valid,
 strict specification.  It is probably an over specification, but that is
 not something the compiler can reasonably detect I would assume.
 Anything that would detect that, I suspect, would make other over
 specifications illegal when they may be valid for future planning.  If
 you can't argue on HOW to prevent the curly form of abuse, then I don't
 see the problem with making it explicit with the shemp syntax.
 Since shemp would be a synonym for curly, it is no less strict that
 curly.  Honestly, I think it makes the lack of a careful promise more
 obvious.  I certainly don't agree with the argument that "It's bad style
 so we should penalize it with the syntax".  If that is our plan then
 let's replace goto with some that takes a few lines and lots of
 redundancy.  Goto has been the root of far more evil than under
 specifying error conditions.


Your argument appears to be that because some people can partly side-step a
language feature it shouldn't be there at all.  I don't agree. I certainly
don't agree that a language feature designed to produce correct code should
be rejected to favour quick hacks.  I think that a lot of the point of
coding in a higher level language than C is that you are aiming to produce
cleaner, more reliable code than you could in C.

Besides, I don't see the difference between having to declare unhandled
exceptions and not being able to have unused variables.  If you have an
unused variable, the D compiler will complain and you will duck into the
code, delete the variable or comment it out (or fix the bug if it was one)
then recompile.  That doesn't seem too difficult a task even for someone in
a hurry.  If you have strict exception specfication the compiler might
complain that your new method isn't handling an exception and should either
catch it or declare it with a throws clause.  You duck into the code and
handle it or pass it on - no big deal.

I also think this 'shem vs curly' issue you raise is something of a
straw-man argument.  If someone wants to go out of their way to abuse
exception specification because they're hacking, then fine - that's their
perogative.  They are free to do that with expection specification.
However, people who want to code clean, reliable, reusable code need to know
that their modules are as good as they can get. If you allow:

method()  // I can throw anything

to mean an method which can throw any exception, then you remove an
incredibly useful tool from the careful programmer's tool chest, because the
compiler can now no longer tell whether the code you are writing is wrong
because you haven't handled an exception or whether you really meant it to
be like that and you wanted all the exceptions to percolate through your
code right out to main and bomb the program.

You have two options: strict exception specification and no exception
specification at all (a halfway measure helps noone as pointed out above).
If you go for no exception specifications, then hackers are happy and people
who want correct code get no help at all (may as well not bother with
design-by-contract either if that's your point of view).  If you go for
strict exception specification, hackers can still hack - using
throws(exception) to their heart's desire, but people aiming to write and
mantain correct code are not penalised, and can get a great deal of support
by the compiler to do so.

I have had experience with maintaining large code bases in C++ and Java
(plus having to do quick hacks - for support reasons - in both languages).
I know from experience that strict exception specification is a major win.
(I don't mean to presume to know anything about your programming experience,
BTW)  I cannot stress strongly enough how much I think ignoring strict
exception specification is a *bad idea*.  C++ takes the weak exception
specfication route because of legacy reasons, and Barney Soupstrain rates it
as one of the biggest regrets he has about C++.  He's right! ;-)

Peter.
Aug 31 2001
prev sibling parent Russ Lewis <russ deming-os.org> writes:
Dan Hursh wrote:


 I think you are mistaking what I am saying.  Exceptions are still
 enforced in my microcosm.  The programmer simply does not need to give a
 throws clause.  In that case, 'throws(exception)' or what ever the
 exception base class is can be assumed.  Face it.  If the programmer is
 lazy or in a rush, he will probably do this anyhow.  You can't prevent
 it without actually making the compiler analyze the enter program to
 make sure the programmer's throws clauses are neither missing something
 nor are they too general.


The compiler can analyze each function individually.  If you throw an exception
in
a function (or call a function that throws an exception that you don't catch)
but
you don't declare it, it's a syntax error.  Then, when you call any function,
you
can guarantee that that function will be bound to only throwing the exception it
declares.  Am I missing something?


 In that case you wouldn't need a throws
 clause because the compiler would figure it out itself.  I don't believe
 that is practical.

 Maybe my original example should have been:

 larry() throws();         // I will throw nothing
 moe() throws(X, Y, Z);    // I might throw X, Y & Z
 shemp();                  // assume I could throw execption (aka anything)
 curly() throws(exception);// I can throw the same things as shemp


If D implements strict exception specification, then the shemp() declaration
should mean an explicit declaration that it throws *nothing*.
Aug 31 2001
prev sibling parent "kaffiene" <kaffiene xtra.co.nz> writes:
 Can I ask a question of everybody on this thread? How many of you have
 actually spent anytime working with a language that has rigorous exception
 specification syntax (eg. Java)? I spent 18 months programming almost
 exclusively in Java and I honestly did not find having to declare


exceptions

 a bother. As for API drift being a problem in this regard, it happens a


hell

 of a lot less than you might imagine - and when it does happen, you can
 relax in the certain knowledge that you're compiler's going to tell you
 about each and every point at which changes in a 3rd party library has
 broken your code.


I've been programming Java/C++/C interchangibly over the past three years.
I've never found exception specification to be a bother in Java, rather I've
found it to be a great help.  I've never shipped code wondering whether some
unforeseen exception might  scuttle it, and quite often I've seen the
compiler complain about some unhandled exception and been pleased that it
did.

Peter.
Aug 30 2001
prev sibling parent Jim Farrand <farrand cs.bris.ac.uk> writes:
Walter wrote:

 
 Here's my problem with a throws clause:
 
 A calls B
 B calls C
 C calls D
 
 D is in some third party library. Now, D is updated to throw another
 exception. Now, the code in C, B, and A all needs to be updated. 


But C, B and A *should* be updated.  If D now throws another type of
exception, there is now something new that can go wrong with D.  C, B
and A need to take account of this - otherwise, what happens when D does
throw this new exception?

IMHO the exceptions thrown by a function are part of it's interface. 
Other interface changes in D would result in changes in code which calls
D.  Why not the same with exceptions?
--
Jim Farrand, ML Group,               mailto:farrand cs.bris.ac.uk
Department of Computer Science,      http://www.cs.bris.ac.uk/~farrand
University of Bristol,               tel: +44-(0)117-954-5254
Woodland Road, Bristol, BS8 1UB, UK
Aug 29 2001