www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What's the best way to find out which exceptions may be thrown ?

reply wjoe <invalid example.com> writes:
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?
May 27 2020
parent reply Mike Parker <aldacron gmail.com> writes:
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)`.
May 27 2020
parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 27 2020
next sibling parent reply wjoe <invalid example.com> writes:
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.
May 27 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 27 2020
parent reply wjoe <invalid example.com> writes:
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.
May 27 2020
next sibling parent Johannes Loher <johannes.loher fg4f.de> writes:
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.
May 27 2020
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
May 27 2020
next sibling parent wjoe <invalid example.com> writes:
On Wednesday, 27 May 2020 at 11:40:00 UTC, Mike Parker wrote:
 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.
Johannes, Dennis, Mike that was very insightful. I didn't consider those reasons. Thank you very much for the elaboration :)
May 27 2020
prev sibling parent reply Bienlein <ffm2002 web.de> writes:
On Wednesday, 27 May 2020 at 11:40:00 UTC, Mike Parker wrote:
 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.
Because of the problems with checked exceptions they were for this decision: https://www.artima.com/intv/handcuffs.html
Jun 02 2020
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 2 June 2020 at 13:58:13 UTC, Bienlein wrote:
 Because of the problems with checked exceptions they were 


 reasons for this decision: 
 https://www.artima.com/intv/handcuffs.html
This wouldn't seem to apply if checked exceptions were inferred by default, right? And the issues with Java generics don't apply to D, because our metaprogramming infers attributes anyways.
Jun 03 2020
prev sibling parent wjoe <invalid example.com> writes:
On Tuesday, 2 June 2020 at 13:58:13 UTC, Bienlein wrote:
 On Wednesday, 27 May 2020 at 11:40:00 UTC, Mike Parker wrote:
 On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:
[...]
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.
Because of the problems with checked exceptions they were reasons for this decision: https://www.artima.com/intv/handcuffs.html
That was a good read. Thank you.
Jun 03 2020
prev sibling parent reply Luis <luis.panadero gmail.com> writes:
On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:
 Could you please elaborate why checked exceptions are more 
 annoying?
Have like 3 functions : A calls B, B calls C . Imagine that now you need to throw a checked exception on C, that before wasn't necessary. You need to add the annoying "throws X" to A and B. And A and B could be on another module or on a different project. Perhaps, the guy that wrote B, was previsor, and putted "throws Exception" (or another generic Exception derived class) on B to avoid problems, but now you have loss the information about the specific Exception that C throws. So again, the compiler can't know what kind of exception could be throwed by A beyond of a generic "Exception" (or another generic exception class). Another workaround, could be wrapping the C throwed exception by a generic exception on B. I work daily with Java, and it's pretty annoying. That the IDE helps you auto putting the throws or suggesting a try/catch, helps. But we ended making some generic exceptions RuntimeExceptions to avoiding the noise and problems that could give checked exceptions.
Jun 03 2020
parent wjoe <invalid example.com> writes:
On Wednesday, 3 June 2020 at 07:19:45 UTC, Luis wrote:
 On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote:
 Could you please elaborate why checked exceptions are more 
 annoying?
Have like 3 functions : A calls B, B calls C . [...] I work daily with Java, and it's pretty annoying. That the IDE helps you auto putting the throws or suggesting a try/catch, helps. But we ended making some generic exceptions RuntimeExceptions to avoiding the noise and problems that could give checked exceptions.
I was thinking about IDE assistance, too, but after reading the interview with Anders Hejlsberg mentioning the ballooning problem - I can see how checked exceptions can get out of control.
Jun 03 2020
prev sibling parent Dennis <dkorpel gmail.com> writes:
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.
May 27 2020
prev sibling parent wjoe <invalid example.com> writes:
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.
May 27 2020