nothrow void foo()
{
   bar(4);
}

void bar(int a)
{
  if (a ==1)
    throw new Exception1();
  else if (a == 2)
    throw new Exception2();

   baz();
}

void baz()
{
  if (whatever)
    throw new Exception3();
}


The compiler will complain that bar(int) isn't nothrow.

What's the best way to find out which Exceptions aren't handled inside of foo() for foo to be able to be nothrow without using a 'catch (Exception){}' catch-all?

On Wednesday, 27 May 2020 at 09:40:08 UTC, wjoe wrote:

>
> The compiler will complain that bar(int) isn't nothrow.
>
> What's the best way to find out which Exceptions aren't handled inside of foo() for foo to be able to be nothrow without using a 'catch (Exception){}' catch-all?

`catch(Exception)`.

On Wednesday, 27 May 2020 at 09:42:58 UTC, Mike Parker wrote:
> On Wednesday, 27 May 2020 at 09:40:08 UTC, wjoe wrote:
>
>>
>> The compiler will complain that bar(int) isn't nothrow.
>>
>> What's the best way to find out which Exceptions aren't handled inside of foo() for foo to be able to be nothrow without using a 'catch (Exception){}' catch-all?
>
> `catch(Exception)`.

I should add that if you're only catching specific exceptions in a `nothrow` function, then it isn't `nothrow`. You have to catch Exception because D does not have exception specifications. I would expect the compiler to complain if you try to do otherwise.

On Wednesday, 27 May 2020 at 09:44:56 UTC, Mike Parker wrote:
> On Wednesday, 27 May 2020 at 09:42:58 UTC, Mike Parker wrote:
>> On Wednesday, 27 May 2020 at 09:40:08 UTC, wjoe wrote:
>>
>>>
>>> The compiler will complain that bar(int) isn't nothrow.
>>>
>>> What's the best way to find out which Exceptions aren't handled inside of foo() for foo to be able to be nothrow without using a 'catch (Exception){}' catch-all?
>>
>> `catch(Exception)`.
>
> I should add that if you're only catching specific exceptions in a `nothrow` function, then it isn't `nothrow`. You have to catch Exception because D does not have exception specifications. I would expect the compiler to complain if you try to do otherwise.

Thanks for the fast reply, Mike.

The problem with catch(Exception) is that it's run time whereas I'd like to know compile time which exception may possibly be thrown.

So I take it the only way to find out what may be thrown is to read the source code of the called function(s) and the rat tail that follows - and to rely on documentation to be accurate and complete if the source code isn't available.

That's sort of annoying.

On Wednesday, 27 May 2020 at 09:44:56 UTC, Mike Parker wrote:
> On Wednesday, 27 May 2020 at 09:42:58 UTC, Mike Parker wrote:
>
> I should add that if you're only catching specific exceptions in a `nothrow` function, then it isn't `nothrow`. You have to catch Exception because D does not have exception specifications. I would expect the compiler to complain if you try to do otherwise.

I should add that the reason for my question wasn't to make a function nothrow by means of not letting Exceptions escape, for which std.exception.assumeWontThrow could be used, but to be able to find out which exceptions can/should be handled at a particular call site.

On Wednesday, 27 May 2020 at 09:56:07 UTC, wjoe wrote:
>
> The problem with catch(Exception) is that it's run time whereas I'd like to know compile time which exception may possibly be thrown.
>
> So I take it the only way to find out what may be thrown is to read the source code of the called function(s) and the rat tail that follows - and to rely on documentation to be accurate and complete if the source code isn't available.
>
> That's sort of annoying.

Checked exceptions are much more annoying. And without them, there's no way (as far as I can see) the compiler can verify what a function may throw without parsing the source of every function a call chain touches. That's rather impractical.

On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote:
> On Wednesday, 27 May 2020 at 09:56:07 UTC, wjoe wrote:
>>
>> The problem with catch(Exception) is that it's run time whereas I'd like to know compile time which exception may possibly be thrown.
>>
>> So I take it the only way to find out what may be thrown is to read the source code of the called function(s) and the rat tail that follows - and to rely on documentation to be accurate and complete if the source code isn't available.
>>
>> That's sort of annoying.
>
> Checked exceptions are much more annoying.

Could you please elaborate why checked exceptions are more annoying?

The only exposure to checked exceptions I had was with Java and I always liked and appreciated them.
It's super annoying the fiddle around with catch(Exception) all over the place and log unhandled Exceptions and never be sure that all exceptions are properly taken care of.

Am 27.05.20 um 12:30 schrieb wjoe:
> 
> Could you please elaborate why checked exceptions are more annoying?
> 
> The only exposure to checked exceptions I had was with Java and I always
> liked and appreciated them.
> It's super annoying the fiddle around with catch(Exception) all over the
> place and log unhandled Exceptions and never be sure that all exceptions
> are properly taken care of.
>
There are several reasons. Walter elaborates on some of them in the thread regarding the acceptance of DIP1028 in the announce section. Another example is the fact that they don't work with functional interfaces in Java: You cannot pass a function that throws checked exceptions to map etc.

On Wednesday, 27 May 2020 at 09:56:07 UTC, wjoe wrote:
> The problem with catch(Exception) is that it's run time whereas I'd like to know compile time which exception may possibly be thrown.

Note that this is impossible in general due to the nature of classes.
A function could at runtime find the latest trending hashtag on twitter, name a class after it that derives from Exception, invoke the compiler to generate a shared library that throws an exception with that class, load that library, and call the newly loaded function that throws the newly created exception class.

Obviously there's no way of knowing this class at compile time.

On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:
> On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote:
> Could you please elaborate why checked exceptions are more annoying?
>

For me, it's because they require all functions that touch them to either try/catch or include an exception specification in its declaration. In my Java days, I ended up just doing what so many others do and adding `throws Exception` or `catch(Exception)` to avoid having to handle multiple exception types. Most of the time, I didn't care what specific sort of exception was thrown.