On Thursday, 29 June 2017 at 21:06:12 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
>> Checked exceptions are a horrible idea because they leak internal implementation details as part of the signature of a method directly and in a transitive manner, which of course is one huge aberration!
>
> What do you mean? Exceptions that leave a module clearly aren't internal implementation details…

Correct!
But I said 'checked exceptions' are.

On Monday, 3 July 2017 at 20:22:39 UTC, Crayo List wrote:
> On Thursday, 29 June 2017 at 21:06:12 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
>>> Checked exceptions are a horrible idea because they leak internal implementation details as part of the signature of a method directly and in a transitive manner, which of course is one huge aberration!
>>
>> What do you mean? Exceptions that leave a module clearly aren't internal implementation details…
>
> Correct!
> But I said 'checked exceptions' are.

How does "checked" affect whether something is internal or not?

On Tuesday, 4 July 2017 at 10:14:11 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 3 July 2017 at 20:22:39 UTC, Crayo List wrote:
>> On Thursday, 29 June 2017 at 21:06:12 UTC, Ola Fosheim Grøstad wrote:
>>> On Thursday, 29 June 2017 at 19:34:22 UTC, Crayo List wrote:
>>>> Checked exceptions are a horrible idea because they leak internal implementation details as part of the signature of a method directly and in a transitive manner, which of course is one huge aberration!
>>>
>>> What do you mean? Exceptions that leave a module clearly aren't internal implementation details…
>>
>> Correct!
>> But I said 'checked exceptions' are.
>
> How does "checked" affect whether something is internal or not?

int open(string file)
{
     if(!exists(file))
        throw new SomeException;

    ...
}

a few weeks later;

int open(string file)
{
    if(file == null)
       threw new NullSomethingException;

     same as before
}

What happens to the 3000 direct and indirect calls to open() ?

Notice how the 'interface' has not changed, only the implementation.

Am Wed, 28 Jun 2017 11:04:58 +0000
schrieb Moritz Maxeiner <moritz@ucworks.org>:

> One could also make an exception for bodyless functions and allow specification of the exception set *only* there, e.g.
> 
> ---
> // Allow "checked exceptions" for stubs only
> void foo() throws AException throws BException;
> ---

Ah, come one, now that you see the need you can also embrace it as an option for people who want to add some documentation.

void foo()
  throws AException  // When the ant's life ends prematurely
  throws BException; // When the ant gets distracted by a lady bug

-- 
Marco

In general, I'm of the opinion that DLL API should be fully
explicit. It's the only way you can reasonably provide
ABI stability. That means no templates, no attribute inference
and explicit exception lists if the compiler were to used them.

-- 
Marco

On Wednesday, 5 July 2017 at 15:48:33 UTC, Crayo List wrote:
> What happens to the 3000 direct and indirect calls to open() ?
>
> Notice how the 'interface' has not changed, only the implementation.

No, the exception spec is part of the interface whether it is in the function declaration  or not. Such a change could be fatal in any system.

What you should do is to specify what Exceptions are thrown across module borders. That means you should recast the internal exceptions into module-level exceptions.

On Wednesday, 5 July 2017 at 20:35:14 UTC, Marco Leise wrote:
> Am Wed, 28 Jun 2017 11:04:58 +0000
> schrieb Moritz Maxeiner <moritz@ucworks.org>:
>
>> One could also make an exception for bodyless functions and allow specification of the exception set *only* there, e.g.
>> 
>> ---
>> // Allow "checked exceptions" for stubs only
>> void foo() throws AException throws BException;
>> ---
>
> Ah, come one, now that you see the need you can also embrace it as an option for people who want to add some documentation.

After some more consideration I would be amenable to automatic inference of the exception set as the default with *optional* manual specification, i.e.

---
void foo() throws AException throws BException { ... }
vod bar() { foo(); }
---

works and bar's exception is inferred by the compiler to contain AException and BException.

But to be clear (and the title and description of any DIP addressing this should reflect this):
These are not checked exceptions, because checked exceptions would require bar to declare its exception set manually.

On Thursday, 6 July 2017 at 01:31:44 UTC, Moritz Maxeiner wrote:
> ---
> void foo() throws AException throws BException { ... }
> vod bar() { foo(); }
> ---
>
> works and bar's exception is inferred by the compiler to contain AException and BException.
>
> But to be clear (and the title and description of any DIP addressing this should reflect this):
> These are not checked exceptions, because checked exceptions would require bar to declare its exception set manually.
 Not checked in sense of Java, but Java has no deductible exceptions. If compiler will fail on `void bar() { foo(); } throws AException;` we still can call it 'checked', I think. In sense of D.

Am Thu, 06 Jul 2017 01:31:44 +0000
schrieb Moritz Maxeiner <moritz@ucworks.org>:

> But to be clear (and the title and description of any DIP
> addressing this should reflect this):
> These are not checked exceptions, because checked exceptions
> would require bar to declare its exception set manually.

Yep, absolutely clear. Just like "auto a = 1" does not declare
a variable as we all know declarations start with a type.
Instead of defining checked exceptions how it bests fits all
your posts in this thread, why not say "Checked exceptions as
implemented in Java were a good idea, had they allowed the
compiler to infer them where possible."
Of course we can still call those inferred checked exceptions
something else. ;o)

-- 
Marco

On Thursday, 6 July 2017 at 11:01:26 UTC, Marco Leise wrote:
> Am Thu, 06 Jul 2017 01:31:44 +0000
> schrieb Moritz Maxeiner <moritz@ucworks.org>:
>
>> But to be clear (and the title and description of any DIP
>> addressing this should reflect this):
>> These are not checked exceptions, because checked exceptions
>> would require bar to declare its exception set manually.
>
> Yep, absolutely clear. Just like "auto a = 1" does not declare
> a variable as we all know declarations start with a type.

Red herring.
Checked exceptions are well defined - not just implemented - (by Java as the de facto authority for the term) as requiring the declaration of all exceptions (that aren't inherited from some special class, in Java's case `RuntimeException`, in D's it would be `Error`) that may be thrown by a function as a result of its body being executed [1]. If even a single function is allowed to have its exception set defined by inference (instead of declaration), you are not implementing checked exceptions.

---
void foo() throws AExp throws BExc { ... }
void bar1() { foo(); } // Checked exceptions require this to result in a compilation error
void bar2() throws AExc throws BExc { foo(); } // this must be used for checked exceptions
---

> Instead of defining checked exceptions how it bests fits all
> your posts in this thread, why not say "Checked exceptions as
> implemented in Java were a good idea, had they allowed the
> compiler to infer them where possible."

Invalid premise. The definition of checked exceptions is de facto fixed by Java [1], because it not only coined the term but remains the only major PL to use them.

> Of course we can still call those inferred checked exceptions
> something else. ;o)

The java compiler does infer an exception set for every function based on its body.
This is then checked against the function's exception set as declared in its signature.
"inferred checked exceptions" is thus an oxymoron, because it would mean checking the inferred exception set against itself.

[1] https://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html