Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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 deliberately left out in C#. Here is an interview with Anders Hejlsberg, the creator of C# at MS, where he explains the reasons for this decision: https://www.artima.com/intv/handcuffs.html That was a good read. Thank you.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
On Tuesday, 2 June 2020 at 13:58:13 UTC, Bienlein wrote: Because of the problems with checked exceptions they were deliberately left out in C#. Here is an interview with Anders Hejlsberg, the creator of C# at MS, where he explains the 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.
Re: What's the best way to find out which exceptions may be thrown ?
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 deliberately left out in C#. Here is an interview with Anders Hejlsberg, the creator of C# at MS, where he explains the reasons for this decision: https://www.artima.com/intv/handcuffs.html
Re: What's the best way to find out which exceptions may be thrown ?
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 :)
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
Re: What's the best way to find out which exceptions may be thrown ?
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.
What's the best way to find out which exceptions may be thrown ?
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?
Re: What's the best way to find out which exceptions may be thrown ?
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)`.
