What about exception specification? Bjarne's 4th biggest mistake was not making exception specification mandatory in C++ right from the get-go.

Cheers,
John Carney.

John Carney wrote in message <9ljd0j$1j66$1@digitaldaemon.com>...
>
>What about exception specification? Bjarne's 4th biggest mistake was not making exception specification mandatory in C++ right from the get-go.
>
>Cheers,
>John Carney.


D ditches the whole exception specification thing. It inhibits code reuse and it is just plain annoying. Not that I have any opinion about it or anything <g>.

"Walter" <walter@digitalmars.com> wrote in message news:9lml50$10vj$1@digitaldaemon.com...
>
> John Carney wrote in message <9ljd0j$1j66$1@digitaldaemon.com>...
> >
> >What about exception specification? Bjarne's 4th biggest mistake was not making exception specification mandatory in C++ right from the get-go.
> >
> >Cheers,
> >John Carney.
>
>
> D ditches the whole exception specification thing. It inhibits code reuse

My experience when doing a stint of Java development a few years back was precisely the opposite.

> and it is just plain annoying.

Yeah, and so are compiler warnings, design-by-contract, type safety and countless other panty-waister schemes designed to get in the way of *real* programmers. Don't know why you're bothering with all this "D" business. We should all go back to pre-C++ era C compilers.

> Not that I have any opinion about it or
> anything <g>.

I see your opinion and raise you... ;-)

"Walter" <walter@digitalmars.com> wrote in message news:9lml50$10vj$1@digitaldaemon.com...
>
> John Carney wrote in message <9ljd0j$1j66$1@digitaldaemon.com>...
> >
> >What about exception specification? Bjarne's 4th biggest mistake was not making exception specification mandatory in C++ right from the get-go.
> >
> >Cheers,
> >John Carney.
>
>
> D ditches the whole exception specification thing. It inhibits code reuse and it is just plain annoying. Not that I have any opinion about it or anything <g>.

I 100% disagree with this.  I think practical experience in dealing with exceptions in Java as opposed to C++ proves the opposite to be true. Exception specification is a major tool for creating code that handles errors gracefully.   The C++ approach more often than not leads to code that leaves all exceptions to a try - catch block in main, where it is too far removed from the problem to do anything usefull with it other than bomb.

The Java approach forces programmers to think about exceptions and deal with them properly (even if they decide to delegate resopnsibility, it is an explicit decision and a dscision which is visible to client code / other programmers.)

Peter.

kaffiene wrote:

> "Walter" <walter@digitalmars.com> wrote in message news:9lml50$10vj$1@digitaldaemon.com...
> >
> > John Carney wrote in message <9ljd0j$1j66$1@digitaldaemon.com>...
> > >
> > >What about exception specification? Bjarne's 4th biggest mistake was not making exception specification mandatory in C++ right from the get-go.
> > >
> > >Cheers,
> > >John Carney.
> >
> >
> > D ditches the whole exception specification thing. It inhibits code reuse and it is just plain annoying. Not that I have any opinion about it or anything <g>.
>
> I 100% disagree with this.  I think practical experience in dealing with exceptions in Java as opposed to C++ proves the opposite to be true. Exception specification is a major tool for creating code that handles errors gracefully.   The C++ approach more often than not leads to code that leaves all exceptions to a try - catch block in main, where it is too far removed from the problem to do anything usefull with it other than bomb.
>
> The Java approach forces programmers to think about exceptions and deal with them properly (even if they decide to delegate resopnsibility, it is an explicit decision and a dscision which is visible to client code / other programmers.)

<rabid-opinion>

Not having exception specifications is like not checking the return code on malloc on the theory that "hey, a segfault will clean it up".

The C++ solution, having catch(...) speciifcations all over, is like calling
exit() every time *any* function fails.

</rabid-opinion>

"Russ Lewis" <russ@deming-os.org> wrote in message news:3B7F3AEA.4E79C687@deming-os.org...

<snip>

> <rabid-opinion>
>
> Not having exception specifications is like not checking the return code
on
> malloc on the theory that "hey, a segfault will clean it up".
>
> The C++ solution, having catch(...) speciifcations all over, is like
calling
> exit() every time *any* function fails.
>
> </rabid-opinion>

:-)

Or like never freeing memory on the basis that it'll get released when the application exits.

Or like never closing file handles because the system will close them when the process dies.

Cheers,
John.

<snip>

> > D ditches the whole exception specification thing. It inhibits code
reuse
>
> My experience when doing a stint of Java development a few years back was precisely the opposite.
>
> > and it is just plain annoying.
>
> Yeah, and so are compiler warnings, design-by-contract, type safety and countless other panty-waister schemes designed to get in the way of *real* programmers. Don't know why you're bothering with all this "D" business.
We
> should all go back to pre-C++ era C compilers.

Seriously Walter, you've got it right on so many other fronts, I'd really like you to reconsider your stance on this one. Think of it this way: if it is decided five years down the track that rigid exception specification is, after all, a good thing, you're going to break an awful lot of code if you try to tack it onto the language. On the other hand, if we in the pro-specification camp turn out to be wrong, then relaxing the rules isn't going to render anybody's code base inoperable.

Cheers,
John Carney.

>
> Seriously Walter, you've got it right on so many other fronts, I'd really like you to reconsider your stance on this one. Think of it this way: if
it
> is decided five years down the track that rigid exception specification
is,
> after all, a good thing, you're going to break an awful lot of code if you try to tack it onto the language. On the other hand, if we in the pro-specification camp turn out to be wrong, then relaxing the rules isn't going to render anybody's code base inoperable.
>
> Cheers,
> John Carney.
>
>

I agree with John on this.  Like him, I learned better from a stint in Java development.  First off, to elaborate on the Java model, there are two base types of exceptions.  Any exception derived from "Exception" is forced to be delcared as throws in a function and you must catch it.  This, you claim, Walter, is annoying, but its also invaluable for clean, safe code. Derivitives of RuntimeException do NOT have to be caught (but if they're not, the program exits with an error message )

Learning the subtles of whether to make your custom exception an Exception derivitive or a RuntimeException derivitive turns out to be an art when you start developing HUGE programs.  But, other point to add onto Johns about how it would be better to make the rules stricter now then relax them later if we're proven wrong, is that anyone who DOESN'T like exception specification can just use runtime exceptions for their own custom code. (Built in normal exceptions would, of course, still have to be caught, but there's a REASON that they're thrown...)

Call me an academic, but I think that's how it should be.  ;)

-Brady

I find exceptions to be quite valuable.  They need to be able to throw messages.  They also need to be "boundable", so that a method can guarantee that it won't propagate certain exceptions, even if a call that it makes throws it.

I don't know whether it matters whether this is done by specifying which exceptions it will pass, or which it won't pass.  The Java approach works pretty well.  (And it *is* annoying.)  I've never seen an example of a language where you guaranteed what you wouldn't throw, so I don't know how that would work.

I do know that Eiffel's preconditions/postconditions can be rather annoying.  A lot of the time I would like to throw an error condition to the calling routine, but this appears to be very discouraged by the Eiffel model.  It seems to want all problems to be handled locally.  So (current design problem) if I'm trying to insert a record into a locked list, Eiffel's answer is, well, you should have asked first.  You should have checked for EOF before you tried to read the file.  A reasonable choice.  Handle errors by preventing their occurance.  But sometimes it can be difficult to do this properly, and then you get run-time assertion errors.  Not good.  And no easy way to "catch and handle" them.

Ada may have a better approach here.  And Java's approach is pretty good.

One thing that needs to be clear:  Is an exception for handling an expectable error?  What's the run-time cost of handling an exception? This isn't always easy to find out, and it could have a big effect on how they would be used.  (Someone once told me that it took 1000 times as long to process an exception as to process a branch.  If this is true, then using them for "exceptional case" handling is ... less desireable.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B816D1F.80309@earthlink.net...

<snip>

> One thing that needs to be clear:  Is an exception for handling an expectable error?  What's the run-time cost of handling an exception? This isn't always easy to find out, and it could have a big effect on how they would be used.  (Someone once told me that it took 1000 times as long to process an exception as to process a branch.  If this is true, then using them for "exceptional case" handling is ... less desireable.


AFAIK the big cost in exception handling is cleaning up the stack.

As an aside, I do recall reading somewhere that in Java, the following code:

    for (i = 0 ; i != anArray.length ; i++)
        doSomething(anArray[i]) ;

could be written faster as:

    try
        {
        i = 0 ;
        while (true)
            doSomething(anArray[i++]) ;
        }
    catch (ArrayBoundsException &x)
        {}

Don't quote me on that - it was a long time ago and may be complete bollocks.

Cheers,
John.