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.

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

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

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

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

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

Walter wrote:
> Every compiler switch is a bug.

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

:-)

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

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

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

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