On 6/12/2013 1:29 PM, Adam D. Ruppe wrote:
> Looking at dmd's source, looks like Walter actually wrote code to parse a throws
> Exception, etc. to be part of the function signature but stripped it out (surely
> because that's annoying).

That detritus should be removed.

It was a bad idea, which is why I disabled it.

On Wednesday, June 12, 2013 13:46:20 Walter Bright wrote:
> On 6/12/2013 1:29 PM, Adam D. Ruppe wrote:
> > Looking at dmd's source, looks like Walter actually wrote code to parse a throws Exception, etc. to be part of the function signature but stripped it out (surely because that's annoying).
> 
> That detritus should be removed.
> 
> It was a bad idea, which is why I disabled it.

Well, I assume that it was the beginnings of a checked exceptions implementations, and checked exceptions do have their advantages, but the general verdict of the programming world as a whole does seem to be that they were ultimately a bad idea. Sometimes, it _does_ suck to not know exactly which exceptions a function can throw, but on the whole, I think that we hit a good balance with nothrow.

What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is.

- Jonathan M Davis

Jonathan M Davis:

> What I find most interesting about checked exceptions is the fact that almost
> everyone thinks that they're a fantastic idea when they first encounter them
> and yet they're actually a bad idea. It's actually a good example of how a
> feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is.

Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better.

Bye,
bearophile

On 6/12/2013 2:21 PM, bearophile wrote:
> Jonathan M Davis:
>
>> What I find most interesting about checked exceptions is the fact that almost
>> everyone thinks that they're a fantastic idea when they first encounter them
>> and yet they're actually a bad idea. It's actually a good example of how a
>> feature sometimes needs to be thoroughly field-tested before it becomes clear
>> how good or bad it is.
>
> Maybe checked exceptions are bad only for the type system of Java. Maybe for a
> language that has global type inferencing on the exceptions such feature becomes
> better.

C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it.

On 6/12/2013 2:21 PM, bearophile wrote:
> Jonathan M Davis:
>
>> What I find most interesting about checked exceptions is the fact that almost
>> everyone thinks that they're a fantastic idea when they first encounter them
>> and yet they're actually a bad idea. It's actually a good example of how a
>> feature sometimes needs to be thoroughly field-tested before it becomes clear
>> how good or bad it is.
>
> Maybe checked exceptions are bad only for the type system of Java. Maybe for a
> language that has global type inferencing on the exceptions such feature becomes
> better.

It's not just Java specific. Bruce Eckel wrote a wonderful piece on why exception specifications *cause* bad code to be written.


http://www.mindview.net/Etc/Discussions/CheckedExceptions

Walter Bright:

>> Maybe checked exceptions are bad only for the type system of Java. Maybe for a
>> language that has global type inferencing on the exceptions such feature becomes
>> better.
>
> C++98 had checked exceptions (exception specifications), too.

C++98 doesn't have a global type inferencer for exceptions.

Bye,
bearophile

On 6/12/13 6:26 PM, Walter Bright wrote:
> On 6/12/2013 2:21 PM, bearophile wrote:
>> Jonathan M Davis:
>>
>>> What I find most interesting about checked exceptions is the fact
>>> that almost
>>> everyone thinks that they're a fantastic idea when they first
>>> encounter them
>>> and yet they're actually a bad idea. It's actually a good example of
>>> how a
>>> feature sometimes needs to be thoroughly field-tested before it
>>> becomes clear
>>> how good or bad it is.
>>
>> Maybe checked exceptions are bad only for the type system of Java.
>> Maybe for a
>> language that has global type inferencing on the exceptions such
>> feature becomes
>> better.
>
> It's not just Java specific. Bruce Eckel wrote a wonderful piece on why
> exception specifications *cause* bad code to be written.
>
>
> http://www.mindview.net/Etc/Discussions/CheckedExceptions

Do you think the same will happen if the compiler tracks possible null references and whenever you might have a null pointer exception you are forced to handle it? (provided that the compiler is smart enough to know when a variable can't be null for sure, for transforming the code to SSA)

On 6/12/13 6:21 PM, bearophile wrote:
> Jonathan M Davis:
>
>> What I find most interesting about checked exceptions is the fact that
>> almost
>> everyone thinks that they're a fantastic idea when they first
>> encounter them
>> and yet they're actually a bad idea. It's actually a good example of
>> how a
>> feature sometimes needs to be thoroughly field-tested before it
>> becomes clear how good or bad it is.
>
> Maybe checked exceptions are bad only for the type system of Java. Maybe
> for a language that has global type inferencing on the exceptions such
> feature becomes better.

Why?

On 06/12/2013 11:23 PM, Walter Bright wrote:
> On 6/12/2013 2:21 PM, bearophile wrote:
>> Jonathan M Davis:
>>
>>> What I find most interesting about checked exceptions is the fact
>>> that almost
>>> everyone thinks that they're a fantastic idea when they first
>>> encounter them
>>> and yet they're actually a bad idea. It's actually a good example of
>>> how a
>>> feature sometimes needs to be thoroughly field-tested before it
>>> becomes clear
>>> how good or bad it is.
>>
>> Maybe checked exceptions are bad only for the type system of Java.
>> Maybe for a
>> language that has global type inferencing on the exceptions such
>> feature becomes
>> better.
>
> C++98 had checked exceptions (exception specifications), too. Another
> failure of the idea, it failed so badly hardly anyone but language
> lawyers ever knew it had it.
>

Weren't those checked at runtime?

On 6/12/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Wednesday, 12 June 2013 at 20:23:43 UTC, Andrej Mitrovic wrote:
>> Are you sure? A compiler can tell whether a function /can/ throw (hence why nothrow works), so I assume it has information on where an exception is thrown.
>
> Consider this:
>
> extern(D) void foo();
> void bar() { foo(); }
>
>
> That's legal D code, and foo could throw anything, and bar would have no idea what it is.

I thought doing this only for function definitions could make sense. For declarations the user would have to do it manually.