10 ms·

Lets be honest. The more likely thing is that either the coworker would use an unchecked exception or that they would change the callsite to: try { theUp

by jabiko 3y ago

Lets be honest. The more likely thing is that either the coworker would use an unchecked exception or that they would change the callsite to: try { theUpdatedFunction(); } catch (MyNewCheckedException e) { logger.warn("Whoopsie doopsie", e) throw new SomeUncheckedException("Something failed, idk", e) } Which really is a zero sum game. The code still breaks the same way, but the checked exception gets eventually wrapped in an unchecked one. We still would have the situation that someone changed the behavior of the function in a way that is incompatible with your usage. That bug should have been caught by tests, code reviews and good communication.

__jem 3y ago
Or, worse, you're reviewing a large diff, see the logger statement but don't notice that the junior whose code you're reviewing forgot to rethrow. Now you've accidentally entered uncharted territory where way more scarier things can happen to your application than just crashing. Of course this shouldn't happen, but it does.
- twelve40 3y ago
  that can be somewhat addressed with decent unit test coverage
doliveira 3y ago
If the Future, Executor, Optional, Streams, etc played nice with checked exceptions it would probably be different. Right now at some point you do have to wrap it into an unchecked exception.
- throwaway2037 3y ago
  I agree. It is weird that for interface Runnable there isn't a ThrowingRunnable. I always create them in my projects and make my callbacks use them along with ThrowingConsumer and ThrowingProvider.
phillipcarter 3y ago
Yep. This is similar to a viewpoint by Anders Hejlsberg and many on the C# team at the time: https://www.artima.com/articles/the-trouble-with-checked-exceptions https://www.artima.com/articles/the-trouble-with-checked-exc... > You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any. And he goes on to elaborate on how this gets more complicated when versioning is introduced into the mix.
- breadwinner 3y ago
  Hejlsberg is a terrific compiler writer. Turbo Pascal was awesome! He is not a good language designer, however. The exception mess in C# is the proof. See my comment at the root of this thread.
  - bheadmaster 3y ago
    I doubt you can evaluate man's skill through a single project. It's not nice to use ad hominem to advertise your own comment.
    - 411111111111111 3y ago
      Their comment was the one that this thread is bases on. They're merely pointing out that the original comment already gave an example why its a mess. I disagree with their point though, in java the lib would've probably just converted the exception to a runtime exception so the API doesn't change...
  - phillipcarter 3y ago
    Yes, not a good language designer responsible for (checks notes) one of the most-used and most-loved programming languages on the planet.
    - interlocutor 3y ago
      Do you mean Turbo Pascal? He didn't design it, Niklaus Wirth did. Or do you mean C#? James Gosling designed most of that (C# got its start by copying 90% of Java). Do you mean TypeScript? That's mostly JavaScript.
coldtea 3y ago
>The code still breaks the same way That's not a valid argument. This is an explicit decision, so they reap what they sowed. One could just as well make the same argument for Optionals, that you can just do: let val = foo.unwrap();
breadwinner 3y ago
> That bug should have been caught by tests, code reviews and good communication. There's a reason we have compile-time checks. If you think compile-time checks should be replaced with additional tests, code reviews and good communication, then you want a scripting language, not a compiled language. You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer.
- insanitybit 3y ago
  > unless you are a really bad Java programmer. Here's the thing. You've just described the vast majority of programmers - bad. They're really fucking bad. And language constructs that lead to bad programmers doing stupid things are, unfortunately making things worse for everyone.
- erik_seaberg 3y ago
  stream.filter(p) requires wrapping checked exceptions in p, or altering the language so that they’re no longer checked. Same with Runnable.
  - chii 3y ago
    or you start doing monads instead, where p operates on a monad (aka, the Optional type). Unfortunately, this ends up propagating out and your entire code base needs to also do this. Tho i reckon it will make your code better in the future, for a short term/temporary pain converting/adding breaking changes etc.
    - erik_seaberg 3y ago
      Yeah, switching to Scala or Kotlin would be the shortest path to do that.
  - masklinn 3y ago
    You could also alter the langage woth for exceptions transparency (swift has something like that with “rethrows“). I don’t think that’s close to sufficient to making checked exceptions work tho, let alone good.
hinkley 3y ago
Let's be really honest try { theUpdatedFunction(); } catch (MyNewCheckedException e) { logger.warn("Whoopsie doopsie", e); throw new SomeUncheckedException(e.message); } There's a special place in Hell for these people, but at least they'll get to see all of their friends again.
- mdaniel 3y ago
  Oooo, lookit you working with professionals; I've seen waaaaaaay too many instances of this shit try { somethingImportant(); } catch (Exception e) { // can't happen } IJ finally started chirping about this other anti-pattern try { doit(); } catch (Exception e) { System.err.println("something didn't work"); // failure to reference "e" is now a yellowbox } I have to constantly ask for them to either log it, or rename the variable to `ignored` to get IJ and future readers on the same page that it was intentionally swallowed
hourago 3y ago
> throw new SomeUncheckedException("Something failed, idk", e) Who does that? It looks like an anti-pattern.
bedobi 3y ago
> That bug should have been caught by tests, code reviews and good communication This is such an unproductive cop out response. The problem could be completely solved by functional error handling, which leverages the compiler to force you to handle exactly the errors than can happen, no more, no less.

by jabiko 3y ago

__jem 3y ago

Or, worse, you're reviewing a large diff, see the logger statement but don't notice that the junior whose code you're reviewing forgot to rethrow. Now you've accidentally entered uncharted territory where way more scarier things can happen to your application than just crashing. Of course this shouldn't happen, but it does.

twelve40 3y ago
that can be somewhat addressed with decent unit test coverage

doliveira 3y ago

If the Future, Executor, Optional, Streams, etc played nice with checked exceptions it would probably be different. Right now at some point you do have to wrap it into an unchecked exception.

throwaway2037 3y ago
I agree. It is weird that for interface Runnable there isn't a ThrowingRunnable. I always create them in my projects and make my callbacks use them along with ThrowingConsumer and ThrowingProvider.

phillipcarter 3y ago

Yep. This is similar to a viewpoint by Anders Hejlsberg and many on the C# team at the time: https://www.artima.com/articles/the-trouble-with-checked-exceptions https://www.artima.com/articles/the-trouble-with-checked-exc... > You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any. And he goes on to elaborate on how this gets more complicated when versioning is introduced into the mix.

breadwinner 3y ago
Hejlsberg is a terrific compiler writer. Turbo Pascal was awesome! He is not a good language designer, however. The exception mess in C# is the proof. See my comment at the root of this thread.
- bheadmaster 3y ago
  I doubt you can evaluate man's skill through a single project. It's not nice to use ad hominem to advertise your own comment.
  - 411111111111111 3y ago
    Their comment was the one that this thread is bases on. They're merely pointing out that the original comment already gave an example why its a mess. I disagree with their point though, in java the lib would've probably just converted the exception to a runtime exception so the API doesn't change...
- phillipcarter 3y ago
  Yes, not a good language designer responsible for (checks notes) one of the most-used and most-loved programming languages on the planet.
  - interlocutor 3y ago
    Do you mean Turbo Pascal? He didn't design it, Niklaus Wirth did. Or do you mean C#? James Gosling designed most of that (C# got its start by copying 90% of Java). Do you mean TypeScript? That's mostly JavaScript.

coldtea 3y ago

>The code still breaks the same way That's not a valid argument. This is an explicit decision, so they reap what they sowed. One could just as well make the same argument for Optionals, that you can just do: let val = foo.unwrap();

breadwinner 3y ago

> That bug should have been caught by tests, code reviews and good communication. There's a reason we have compile-time checks. If you think compile-time checks should be replaced with additional tests, code reviews and good communication, then you want a scripting language, not a compiled language. You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer.

insanitybit 3y ago
> unless you are a really bad Java programmer. Here's the thing. You've just described the vast majority of programmers - bad. They're really fucking bad. And language constructs that lead to bad programmers doing stupid things are, unfortunately making things worse for everyone.
erik_seaberg 3y ago
stream.filter(p) requires wrapping checked exceptions in p, or altering the language so that they’re no longer checked. Same with Runnable.
- chii 3y ago
  or you start doing monads instead, where p operates on a monad (aka, the Optional type). Unfortunately, this ends up propagating out and your entire code base needs to also do this. Tho i reckon it will make your code better in the future, for a short term/temporary pain converting/adding breaking changes etc.
  - erik_seaberg 3y ago
    Yeah, switching to Scala or Kotlin would be the shortest path to do that.
- masklinn 3y ago
  You could also alter the langage woth for exceptions transparency (swift has something like that with “rethrows“). I don’t think that’s close to sufficient to making checked exceptions work tho, let alone good.

hinkley 3y ago

Let's be really honest try { theUpdatedFunction(); } catch (MyNewCheckedException e) { logger.warn("Whoopsie doopsie", e); throw new SomeUncheckedException(e.message); } There's a special place in Hell for these people, but at least they'll get to see all of their friends again.

mdaniel 3y ago
Oooo, lookit you working with professionals; I've seen waaaaaaay too many instances of this shit try { somethingImportant(); } catch (Exception e) { // can't happen } IJ finally started chirping about this other anti-pattern try { doit(); } catch (Exception e) { System.err.println("something didn't work"); // failure to reference "e" is now a yellowbox } I have to constantly ask for them to either log it, or rename the variable to `ignored` to get IJ and future readers on the same page that it was intentionally swallowed

hourago 3y ago

> throw new SomeUncheckedException("Something failed, idk", e) Who does that? It looks like an anti-pattern.

bedobi 3y ago

> That bug should have been caught by tests, code reviews and good communication This is such an unproductive cop out response. The problem could be completely solved by functional error handling, which leverages the compiler to force you to handle exactly the errors than can happen, no more, no less.