On Tuesday, 27 June 2017 at 22:56:47 UTC, Moritz Maxeiner wrote:
>
> You mean the very first time you want to call it and you don't know the exception set yourself by looking at its signature?
> Put the call in a nothrow scope and compile the module (which is fast in D), the compiler will then complain which exceptions you didn't catch (requires improvement of nothrow analysis [1]).
>

So to know what exceptions are possible you have to compile the code? I consider that inferior to other solutions such as callee explicitly stating what exceptions it may throw, because then all you have to do is glance at the callee. Also, I think explicitly stating your intent in this manner (by the callee not just the caller) is a good idea, to make sure you are not throwing some exception you didn't mean to throw.

On Wednesday, 28 June 2017 at 01:35:32 UTC, mckoder wrote:
> On Tuesday, 27 June 2017 at 22:56:47 UTC, Moritz Maxeiner wrote:
>>
>> You mean the very first time you want to call it and you don't know the exception set yourself by looking at its signature?
>> Put the call in a nothrow scope and compile the module (which is fast in D), the compiler will then complain which exceptions you didn't catch (requires improvement of nothrow analysis [1]).
>>
>
> So to know what exceptions are possible you have to compile the code?

That, or do the even faster thing and use what's written in the documentation (which a sensible person might generate automatically, embedding the generated exception set for each function).
There are only two outcomes (sans compiler bugs):
- What's written there is correct -> It will compile and you're fine
- What's written there is incorrect -> It won't compile and tell you what's missing
In the 2nd case you have discovered a bug in whatever codebase you are using. Report it.

> I consider that inferior to other solutions such as callee explicitly stating what exceptions it may throw, because then all you have to do is glance at the callee.

On the one hand you have a small one-time cost (I would go as far as calling it tiny, since I consider it a reasonable assumption for you to have the documentation open), on the other hand you have a one-time cost with its size depending on the call hierarchy level and small constant maintenance costs on every change.
If you consider the first inferior to the second, that's your call, but I disagree strongly.
That being said, nothing prevents you from putting it there anyway:

---
static assert (throwsExactly!(foo, AException, BException));
void foo() { ... }
---

> Also, I think  explicitly stating your intent in this manner (by the callee not just the caller) is a good idea, to make sure you are not throwing some exception you didn't mean to throw.

Add a static assert as shown above and you're done.

On Wednesday, 28 June 2017 at 02:09:40 UTC, Moritz Maxeiner wrote:
>
> ---
> static assert (throwsExactly!(foo, AException, BException));
> void foo() { ... }
> ---

One could even go a bit farther and implement a mixin template using `typeof(this)` and do:

---
void foo()
{
    mixin ThrowsExactly!(AException, BException);
}
---

On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
> the good *way* to achieve this result would be the following:
> - When visiting `startFoo`, the compiler automatically aggregates all different exceptions it may throw and stores the resulting set
> - If `startFoo` is going to be part of a (binary) library and its symbol is exported, also export its exception set
> - Improve the compiler's nothrow analysis such that if startFoo is called in scope S, but all of the exceptions in its exception set are caught (i.e. can't break out of scope S), it is treated as nothrow in S.
> - Enclose the call to `startFoo` in B in a nothrow scope.

So I have this .dll. How do I specify which exceptions it throws?

--
  Biotronic

On Wednesday, 28 June 2017 at 06:31:40 UTC, Biotronic wrote:
> On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:
>> the good *way* to achieve this result would be the following:
>> - When visiting `startFoo`, the compiler automatically aggregates all different exceptions it may throw and stores the resulting set
>> - If `startFoo` is going to be part of a (binary) library and its symbol is exported, also export its exception set
>> - Improve the compiler's nothrow analysis such that if startFoo is called in scope S, but all of the exceptions in its exception set are caught (i.e. can't break out of scope S), it is treated as nothrow in S.
>> - Enclose the call to `startFoo` in B in a nothrow scope.
>
> So I have this .dll. How do I specify which exceptions it throws?

- Static/Dynamic linking: As said in bullet point two above, the exception set would have to be exported (more precise: in such a way that it can be loaded again at compile time); there are several ways to go about that: Add the exception set (e.g. via attributes) to the function declarations in a .di file (which could indeed look like checked exception, except that it's auto generated), use a separate (binary) file with mangled functions names to exception set mapping, etc.
- Dynamic loading: Won't work

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

On Tuesday, 27 June 2017 at 16:54:08 UTC, Sebastien Alaiwan wrote:
> adorned with a do-try block, or a try!, or a try?. There is no way, in this language, to silently throw an exception all the way to the top level; without paving a super-hiway for it up through the entire calling tree."

I don't think this is the best argument, if the programmer wants to reduce the number of exceptions that are propagated then the exception should be recast to a more abstract exception between module boundaries.

So the "super highway" issue is more a result of the programmer not being interested in structuring error-handling, but rather view errors as something that never should happen. Which may make sense in some applications, but not in all.

On 06/25/2017 01:38 PM, mckoder wrote:
> I am disappointed that D doesn't have checked exceptions.
> 

Huh? Is it April 1st?

On Monday, 26 June 2017 at 15:40:19 UTC, mckoder wrote:


> Here's the point: with checked exceptions good programmers can write good code. Without checked exceptions even good programmers are forced to write bad code.

This statement is logically equivalent to "good code can only be written with checked exceptions (presumably using Java), all other code is bad".

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!

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…

On Wednesday, June 28, 2017 21:47:56 Nick Sabalausky  via Digitalmars-d wrote:
> On 06/25/2017 01:38 PM, mckoder wrote:
> > I am disappointed that D doesn't have checked exceptions.
>
> Huh? Is it April 1st?

That was kind of my reaction. It has been my impression that while many folks initially seem to think that checked exceptions are a good idea, it has generally been accepted by the programming community at large that they are in fact a bad idea. AFAIK, Java is the only language to have checked exceptions, and every language that has come after has avoided them.

Regardless, based on what Walter has said previously, I think that it's quite clear that there is zero danger of checked exceptions ever being added to D and thus there is really no need to spend time or energy arguing about it, which is part of why I've essentially ignored this thread (and is probably why a lot of major posters have ignored it). I have too little time to spend on D-related things right now as it is. LOL. On that count, I probably shouldn't even have spent the time to reply to this...

- Jonathan M Davis