Hacker News Reader

Comment by wellpast | Hacker News Reader

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."

View on HN

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/diff...

Yeah, Durian pretty much saves my life.

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.

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.

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.

When a program is shutting down, its threads are interrupted.

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);
    }

    try {
        Thread.sleep(1000);
    } catch (final InterruptedException e) {
        LOG.info("Woken up early", e);
    }

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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com