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

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

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

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

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.

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

"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

> P.S. Idea: Exceptions should know what file and line they were thrown from by default.**

Yes.

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