5 ms·

This is flawed thinking. I'd say in many cases it is perfectly desired to either swallow or re-throw exceptions. As just one example, many business rules can b

This is flawed thinking. I'd say in many cases it is perfectly desired to either swallow or re-throw exceptions. As just one example, many business rules can be correctly implemented as best-effort and if some resource (network or service) is unavailable simply let the failure propogate, or log, or backoff and retry some other time. And most certainly but in fewer cases more robust handling is called for. Even if only 10% of exception handling is in this category, then try/catch is still a valuable tool. I find it really faulty to reason that "this feature is only used 'correctly' 10% of the time, therefore it's a failed feature."

draw_down 10y ago
That's what I was thinking. Maybe once in a while I just want to catch a parsing error specifically (like when parsing a string into a number) and then other times I just want to hear when anything goes wrong with some operation. That's not necessarily a misuse of exception handling.
gsmethells 10y ago
The diaper pattern is a well-know anti-pattern. But the idea that all exceptions are thus evil is a giant leap of logic that is hard to swallow.
- emsy 10y ago
  At least in Java, exceptions are often very granular, when you actually don't care. Let's say you want to read a file. You may get an exception for malformed paths, permission errors, filesystem errors and so on. It's unlikely that I will recover from any of these errors during runtime. The only thing I really can do is log the error, inform the user and send a report.
  - sgift 10y ago
    My usual use case involves adding that file to a "retry later" queue. Just logging it and hoping for the best doesn't cut it if you really need to read the file. But maybe I'm an outlier. Most files I see have to be processed, either now or later, without any manual interaction.
  - marcosdumay 10y ago
    Very granular, and not hierarchical enough. What is ironical for Java. Going either way would fix the problem. There's also a lack of support for them in generics. The checked exceptions problem on Java is one of overall language and libraries design, not inherent on the checked exceptions idea.
    - emsy 10y ago
      You're right, in fact I'd argue that checked exceptions are a very good idea. A checked exception is java's way to say: Here is a side effect, take care of it. The problem is that it can't be enforced consequently, partially because Java allows objects to be null. Otherwise checked exceptions would be akin to monads.
- wellpast 10y ago
  Diaper pattern - Never heard that before but I like it and it's accurate. I prefer to catch Exceptions that I know how I want to handle and handle them accordingly. For other exceptions, I prefer to let them fly. If and when they happen, I can then understand the scenario and implement the desired logic.
etwigg 10y ago
This is especially true with Java 8's lambda syntax and method references. Because a Java function's signature includes its checked exceptions, implementing a functional interface can require lots of verbose nested try-catches. e.g. rather than being able to write: foodOnPlate.forEach(this::eat); You end up having to write: foodOnPlate.forEach(food -> { try { eat(food) } catch (Barf e) { // handle? rethrow as unchecked? } }); This library does a pretty god job handling that case: https://github.com/diffplug/durian/blob/master/test/com/diffplug/common/base/ErrorsExample.java?ts=4 https://github.com/diffplug/durian/blob/master/test/com/diff...
- cbsmith 10y ago
  Yeah, Durian pretty much saves my life.
wellpast 10y ago
Here's a common pattern for sleeping on a thread you do not expect to be interrupted and both are equally valid and fine ways to implement it: try { Thread.sleep(1000); } catch (InterruptedException e) { throw new IllegalStateException(e); } try { Thread.sleep(1000); } catch (InterruptedException e) { // never happens } In other words, the correct handling is to swallow or throw. The former is likely preferred by those who do assertion-based coding. The latter for people that prefer to discover their bugs in other ways.
- coredog64 10y ago
  One should never expect a thread not to be interrupted. When I see code like the latter in PRs it drives me nuts, to the point that I start building up a case to have the knucklehead that does it moved off onto another project.
  - wellpast 10y ago
    Why should one always expect a thread to be interruptible? If I don't run my thread within an Executor or some other framework that could interrupt my thread, then I should be able to consider that an illegal state.
    - BrandonM 10y ago
      When a program is shutting down, its threads are interrupted.
- cbsmith 10y ago
  Well, I agree the correct behaviour is to either swallow or throw, but I'd argue it is more like: try { Thread.sleep(1000); } catch (final InterruptedException e) { //never happens throw new IllegalStateException(e); } or try { Thread.sleep(1000); } catch (final InterruptedException e) { LOG.info("Woken up early", e); }

draw_down 10y ago

That's what I was thinking. Maybe once in a while I just want to catch a parsing error specifically (like when parsing a string into a number) and then other times I just want to hear when anything goes wrong with some operation. That's not necessarily a misuse of exception handling.

gsmethells 10y ago

The diaper pattern is a well-know anti-pattern. But the idea that all exceptions are thus evil is a giant leap of logic that is hard to swallow.

emsy 10y ago
At least in Java, exceptions are often very granular, when you actually don't care. Let's say you want to read a file. You may get an exception for malformed paths, permission errors, filesystem errors and so on. It's unlikely that I will recover from any of these errors during runtime. The only thing I really can do is log the error, inform the user and send a report.
- sgift 10y ago
  My usual use case involves adding that file to a "retry later" queue. Just logging it and hoping for the best doesn't cut it if you really need to read the file. But maybe I'm an outlier. Most files I see have to be processed, either now or later, without any manual interaction.
- marcosdumay 10y ago
  Very granular, and not hierarchical enough. What is ironical for Java. Going either way would fix the problem. There's also a lack of support for them in generics. The checked exceptions problem on Java is one of overall language and libraries design, not inherent on the checked exceptions idea.
  - emsy 10y ago
    You're right, in fact I'd argue that checked exceptions are a very good idea. A checked exception is java's way to say: Here is a side effect, take care of it. The problem is that it can't be enforced consequently, partially because Java allows objects to be null. Otherwise checked exceptions would be akin to monads.
wellpast 10y ago
Diaper pattern - Never heard that before but I like it and it's accurate. I prefer to catch Exceptions that I know how I want to handle and handle them accordingly. For other exceptions, I prefer to let them fly. If and when they happen, I can then understand the scenario and implement the desired logic.

etwigg 10y ago

This is especially true with Java 8's lambda syntax and method references. Because a Java function's signature includes its checked exceptions, implementing a functional interface can require lots of verbose nested try-catches. e.g. rather than being able to write: foodOnPlate.forEach(this::eat); You end up having to write: foodOnPlate.forEach(food -> { try { eat(food) } catch (Barf e) { // handle? rethrow as unchecked? } }); This library does a pretty god job handling that case: https://github.com/diffplug/durian/blob/master/test/com/diffplug/common/base/ErrorsExample.java?ts=4 https://github.com/diffplug/durian/blob/master/test/com/diff...

cbsmith 10y ago
Yeah, Durian pretty much saves my life.

wellpast 10y ago

Here's a common pattern for sleeping on a thread you do not expect to be interrupted and both are equally valid and fine ways to implement it: try { Thread.sleep(1000); } catch (InterruptedException e) { throw new IllegalStateException(e); } try { Thread.sleep(1000); } catch (InterruptedException e) { // never happens } In other words, the correct handling is to swallow or throw. The former is likely preferred by those who do assertion-based coding. The latter for people that prefer to discover their bugs in other ways.

coredog64 10y ago
One should never expect a thread not to be interrupted. When I see code like the latter in PRs it drives me nuts, to the point that I start building up a case to have the knucklehead that does it moved off onto another project.
- wellpast 10y ago
  Why should one always expect a thread to be interruptible? If I don't run my thread within an Executor or some other framework that could interrupt my thread, then I should be able to consider that an illegal state.
  - BrandonM 10y ago
    When a program is shutting down, its threads are interrupted.
cbsmith 10y ago
Well, I agree the correct behaviour is to either swallow or throw, but I'd argue it is more like: try { Thread.sleep(1000); } catch (final InterruptedException e) { //never happens throw new IllegalStateException(e); } or try { Thread.sleep(1000); } catch (final InterruptedException e) { LOG.info("Woken up early", e); }