Hacker News Reader

Comment by alasdair_ | Hacker News Reader

I like checked exceptions. Yes, sometimes (especially in the oldest APIs when they were still figuring this stuff out), they were overused but mostly I think they encourage developers to really think about what happens in the failure case.

I notice this especially with less experienced developers and remote calls - a lot of JS code I’ve reviewed in the past assumes the remote call will always work, yet Java code from the same developer will almost always correctly handle the situation, simply because the exception is explicitly required to be handled.

View on HN

Right.

They don't just "encourage" developers to consider error paths, they "force" them to do so.

The concept of checked exceptions is very sound, as is the more general concept of compiler enforced error checking. Very, very few languages have that (only Java and Kotlin in the mainstream league).

Languages with a solid implementation of algebraic data types offer a good first step in that direction but they still require users to manually bubble and compose monadic values, which introduces an unnecessary, and sometimes intractable, level of obfuscation and boiler plate.

All other languages provide weaker approaches to this concept that are library enforced, not language enforced, and therefore more prone to being overlooked since they require discipline from the developer.

You are not forced per se, and can have the same level of obsfucation. It's pretty common to find code ignoring exceptions or wrapping them in RuntimeExceptions, like:

  try {} catch (Exception e) {
    throw new RuntimeException(e);
  }

Also not doing nothing, or the famous catch and log

You aren't forced to handle it well, you are forced to handle it.

You aren't forced to write your happy path code well, either. What's your point?

The point seemed to be that checked exceptions are a bit of a help, whereas you seem to be responding to an implied claim that they aren't helpful. I think that's why you're being downvoted.

Perhaps. I definitely read it as them saying checked exceptions aren't helpful because you can still handle the errors poorly. But I can see how I might have misinterpreted the intent.

I suppose I wasn't clear. You did misinterpret what I said, I intended to convey the exact opposite.

Once upon a time, I worked on a C++ project with another, experienced developer who kept commenting out -Wall from the Makefiles with the comment, "Nobody has time for that."

At which point it's super easy to identify in code review and slap the developer on the wrist.

I find these arguments that posit incompetent / ignorant developers as a hurdle a bit strange. If they are going to incompetently handle errors wrong when explicitly forced to handle them I can't even imagine how poor their code will be without any assistance from the compiler, and it seems awful to think that you will have no way to identify such poor handling on review - you're going to have to look up every function they call and check if it can return an error or not manually.

i.e. Go. Go can make sure you are aware that an error exists (often. linters do pretty good here too), but it does next to nothing to help you handle it correctly.

From personal experience: yes, little to no compiler help on errors takes an enormous amount of effort by both authors and reviewers (and future readers) to ensure correct handling. The vast majority of the time it's just `if err != nil { return err }`, which is very frequently sub-optimal. But without knowing the call in complete detail, you can't judge if that's true or not... and it may have changed since you last saw it.

IDEs help that kind of "is this optimal/correct" question quite a lot, but they can't verify it either. It's question-marks all the way down, unless you fully know all the code you call, which is often infeasible.

The dev may need to. If you are implementing an interface method and the signature does not include the exception, it must be wrapped in the implementation. You’d like this not to be the case, but it’s better than trying to rewrite major dependencies. I hope they can find a more specific RuntimeException subclass to throw, but that’s a relatively minor quibble.

I’d like to suggest a different POV for your comment on code review. Every method can throw exceptions, that’s life with the JVM. You don’t declare IllegalArgumentException, ArrayOutOfBoundsException, NoSuchElementException, etc. Yet your code needs to deal with it and usually does nothing because it means the element doesn’t make it into a collection, the rest of the object doesn’t get constructed, etc. Avoiding raw RTE, and instead using an RTE subclass that conveys the information you care about works fine. Code review avoids raw RTE, and all places that might care about IO exception causes etc. can process the caused-by of the wrappers.

In what kind of code has this technique been an actual problem? I agree standards and techniques need to be rigorously applied.

You are still forced to deal with it.

In your example, the developer just chose to write crappy code, and there's no defense against that.

Not sure if Rust counts as mainstream by your metric, but it does have compiler enforced error handling in the form of the Result sum type.

Kotlin has no mechanism to force error handling. You may suggest that we use sealed classes as return values and match on them, which is okay-ish, but suffers from two big issues:

1. You are not forced to use the result, so if you call a function for its side effects, the compiler will not warn you that you should unwrap the value. Rust and Swift do not have this issue.

2. This is extremely tedious, as you mention. But it's specific to Kotlin and not generally true as you later suggest. Haskell had monad comprehension (do notation), Scala has the same thing, Rust has the ? operator.

Also, regarding Kotlin; no library, nor the standard library, does anything other than throw unchecked exceptions on all kinds of failures. Kotlin is a step backwards, IMO.

Also PHP has checked exceptions, like Java.

> Kotlin has no mechanism to force error handling.

I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler. This is pretty unique to Kotlin at the moment (honorable mention to Ceylon which offered similar support).

Unique to Kotlin? Don’t Swift and TypeScript have this feature too?

Maybe it’s just the languages I’ve been working with this recently, but I think of this as something that’s breaking into the mainstream as language designers are starting to agree that it’s a good idea.

I like Kotlin's null most of the time, but I actually prefer Option still because every once in a while I need to nest them. You can nest Option, but not null.

I think you should look into some more programming languages before you claim that this is unique to Kotlin. ;)

> I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler.

Option/Maybe is enforced by the compiler on most languages that have it. Nullability as part of type signatures differs not because it is compiler-enforced, but because it is not nestable; it provides no equivalent of Maybe[Maybe[T]].

> This is pretty unique to Kotlin at the moment.

C# 8, Python’s typing module, Java 8 via the Nullness Checker, Sorbet for Ruby, and lots of other statically-typed languages or static-analysis packages for languages (even dynamically-typed languages) provide nullability enforcement. It's definitely not unique to Kotlin.

> Option/Maybe is enforced by the compiler on most languages that have it.

It's enforced by exactly zero languages.

It's up to the developer to decide that their function should return an Option/Maybe instead of the naked value.

By definition, any library construct is NOT enforced by the compiler, because... well, it's a library construct and not a language construct.

> It's enforced by exactly zero languages.

It's enforced in exactly the same way a nullability constraint is; if you don't use Maybe[T] instead of T , you can't use None (presuming T itself isn't Maybe[U]), just as if you don't use a nullable type you can't use null.

2 specifically, just to um-actually a minor detail: Rust does have this problem. This code: https://repl.it/repls/LoathsomeCompleteColdfusion

    #[must_use]
    fn get() -> i32 { 
      5
    }

    fn main() {
      get();
    }

will compile and run. It does emit a warning by default at least though:

    warning: unused return value of `get` that must be used
     --> main.rs:7:3
      |
    7 |   get();
      |   ^^^^^^
      |
      = note: `#[warn(unused_must_use)]` on by default

Without the `#[must_use]`, you won't even get that warning. Result has it, so it's common, but it's definitely not enforced. To get the Result's value though, yes - there's no way around it.

You said you were picking on my second point, but you actually addressed the first.

I was specifically talking about Result and Option, which, as you mentioned, are marked must_use. It's correct that it's a warning, but I think that's good enough. You won't accidentally forget to use it.

> compiler enforced error checking. Very, very few languages have that

  __attribute__ ((warn_unused_result))

in C/C++ with GCC and Clang is great.

And standardized as [[nodiscard]] in C++17.

Interesting, thanks.

https://en.cppreference.com/w/cpp/language/attributes/nodisc...

I conjecture that much of the legitimate pain from checked exceptions in Java were because the language to talk about exceptions was so limited.

For instance, consider fold or map functions. There was no way of saying "this might throw anything that might throw", so the only option was "this won't throw anything and that cannot throw anything" or "this might throw anything".

Without the necessary flexibility, developers aren't "forced" to consider only error paths but also manifold impossible paths that aren't easily distinguished from legitimate error paths.

Avoiding the “boilerplate” of error handling means that you have implicitly coupled code now. Exceptions make local reasoning not possible. I guess you may want that in a small minority of cases, but I don’t understand the benefit they give you overall. It’s just a shortcut and a hack, and I’d rather see explicit control flow 100% of the time.

> hey encourage developers to really think about what happens in the failure case.

It's a noble goal, but once I started thinking about what happens in the failure case, I came to the conclusion that checked exceptions are no help here:

- there are always unchecked exceptions. I found it useful to think that any function might throw. So if extra reporting or graceful shutdown are required, just catch everything

- in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate.

> in most cases I have no idea how to recover from error: just keep throwing it to the caller until someone knows what to do. I want it to be the default behavior and I don't want to clutter my code with all the catch-wrap-rethrow boilerplate.

What's your alternative? Using return values? But then you are doing the bubbling, manually.

Exceptions offer a more elegant and less boiler plate approach to this problem: if your code can't handle an exception, just declare it in your signature and ignore it. This is really the best approach to this problem:

- The error cases are part of the function's signature (as they should). - The language takes care of bringing the exception to the right handler. - Your code can proceed with the assumption that all the values are sound.

I've found that in practice it leads to very generic exception names.

When a new failure mode is found for a lowlevel component, in other languages devs would add a new specific exception and things would generally work. In Java, devs have to modify every intermediate component to handle or pass the new exception type so they end up just using an existing one that is super generic.

>What's your alternative? Using return values? But then you are doing the bubbling, manually.

Huh? The alternative is unchecked exceptions, which are already present in Java and therefore have to be accounted for anyway.

Removing checked exceptions from Java would greatly simplify the APIs that use them, with absolutely zero cost.

Return values are a million times better than checked exceptions because return values compose and return values don't collide with the rest of the langugage.

Checked exceptions are basically monads but with all the disadvantages of monads but none of the advantages. There is a reason no language since has copied them.

Except that many languages just do worse. Go, Kotlin, Clojure (very different philosophy, though), C#...

IMO the solution is to either:

* Use return values and let people deal with the boilerplate ala Optional in java. We use Optionals to replace null values and IMO the boilerplate is 100% worth it. I've also used return values that can encode possible errors in Java.

* Use unchecked exceptions and expect people to understand the methods they call and the exceptions those methods can throw, which should be documented in javadoc instead of a throws clause. This needs to happen regardless, as methods can throws unchecked exceptions the caller might need to be aware of, so this in reality doesn't involve extra work.

For me, either of these solutions is preferrable to checked exceptions.

Agreed that the boilerplate of Optional is worth it. That doesn't mean it's actually good. With Java it's just a choice between "bad" and "worse".

> Return values are a million times better than checked exceptions because return values compose

No they don't, not even when they're monads (you need monad transformers to compose monads since they don't universally compose).

Technically you only need swap (eg:

  swap :: Either e2 (Either e1 a) -> Either e1 (Either e2 a)
  swap (Left z) = (Right (Left z))
  swap (Right (Left y)) = (Left y)
  swap (Right (Right x)) = (Right (Right x))

) to implement join (at the functor `Either e1 . Either e2`) and then a general monad-compose. You could also use:

  join :: f1 (f2 (f1 (f2 a))) -> f1 (f2 a)
  -- join = fmap join . join . fmap swap -- if you have swap

directly, which doesn't even require f1 and f2 to be monads in the first place (though they do need to be applicative for return/pure/unit). (See http://web.cecs.pdx.edu/~mpj/pubs/RR-1004.pdf for technical details.)

swap is generally trivial (see above) for any sane error-reporting monad, although might be a bit more difficult if you're shoving error-handling logic into them.

Unchecked exceptions were intended for problems that your code shouldn't really be expected to handle; catching them at the top-level, reporting the error, and letting the user figure out what to is about the only reasonable answer.

Checked exceptions are part of your API, things that your code should be dealing with, and catch-wrap-rethrow is often the right thing. It only becomes a problem with Java programmer's tendency towards thin, shallow abstractions.

> there are always unchecked exceptions

I’m not sure this is necessarily true.

There are always unchecked Throwable’s, but exceptions and Errors are quite distinct things.

I tend to also point out in a lot of these discussions that "checked exceptions" and "java's implementation of checked exceptions" are different things.

Java's implementation has undeniable issues, e.g. in designing stuff with callbacks. It can and often does lead to "everything's runtime" or "everything throws Exception" or other hell-scapes people have heard of. Personally I still prefer them, for pretty much the same reason you mentioned - they are effective, especially with a bit of restraint.

Checked exceptions as a concept are not bound to that. And I wish more languages would make use of them. They can be just as flexible as ADTs, which are pretty widely approved of... because they describe exactly the same thing, just short-circuiting rather than requiring an explicit return. On that front, it's "exceptions" vs "returns" and there are plenty of opinions and tradeoffs between them.

Perhaps because the complexity budget of trying to get checked exceptions right is so high that no one even bothers to try. Once you find yourself able to just return values representing an ADT, then why bother? If the point of a checked exception is that the caller should try handling it immediately, then just return a value like IO<T> instead of return T but maybe throw IOException.

But Java has no language support for dealing with a Try/Result type. It would be objectively worse than just using checked exceptions, IMO.

It's definitely not ideal, but I use Optional to replace nulls in Java and I think it works fine. Similarly you can return values that could represent an error. Or, you can throw an unchecked exception. Callers should be aware of all exceptions a method can throw, especially since those can include unchecked exceptions the compiler doesn't tell you about. Since the caller should do this work anyways, using unchecked exceptions is more than acceptable.

Optional is okay. Of course, you could still be a real jerk and return null instead of Optional<T> and the compiler won't warn me at all and I'll just get an NPE at run time... But it probably won't happen.

The problem with Try/Result is that you still have to do manually unwrapping and/or early returns. Scala and Haskell have monad comprehensive to make this less noisy. Rust has the ? operator. Java has nothing. This makes your code WAY more noisy than having a try-catch inside your non-trivial function.

In a proper world, callers should NOT be aware of all exceptions a function can throw. That's exactly the point of having checked and unchecked exceptions. Checked means the library author thought there is a chance that you might want to handle the exception locally. Unchecked means the library author does not want you to try to recover- they've already determined you're screwed.

I don't think this is true in theory or in practice. Java's Integer.valueOf(String) throws an unchecked exception if it fails, and you should very much be aware of it and catch it in many situations.

Also, in many situations, it doesn't make sense to catch IOException but rather let it propagate. The set of exceptions you should not be expected to catch is generally a very narrow subset of unchecked exceptions, like java.lang.LinkageError or NPE due to internal bug in the called method.

Ack. Totally agree about Integer.valueOf. I think I agree about IOException, too. Definitely most other people agree that it should've been unchecked and that does seem reasonable, as long as it's really only thrown for "oh shit- someone unplugged the hard drive" errors.

I still think that in theory, the distinction I articulated would be proper.

I'd always prefer returning algebraic data types rather than checked exceptions if I were inventing a new language. But given that Java has nothing in the way of that, I'd still say that one should attempt to follow the hypothetical distinction I articulated, even if Java itself fails at it...

It depends on your ADT implementation, but sometimes yes. E.g. Rust makes a pretty good case for not needing exceptions, with the `?` operator, implicit "into" conversions, and a `match` operator that allows returning from the func and not just from the match branch's closure.

In a language without some or all of those (or without ADTs at all, you could have them just for exceptions for instance), ADT-matching to many specific types can get pretty onerous... or you need to do an equivalent to the "catch Exception -> throw RuntimeError" safety-erasing nonsense that this article is rightfully claiming is a problem. Shoving error-types into a separate bucket though often leaves you with a single "return" type, possibly also removing generics entirely, which is trivial to deal with in the happy path in all cases. Optimizing code for the happy path is one of the reasons people like exceptions, so that's potentially significant.

---

edit: ah, no, IMO a large part of the point of exceptions at all (checked included) is that the caller can ignore it by forwarding it implicitly, punting it up the chain without effort. Checked largely just makes sure it's visible in your type signature so you cannot do that silently, unlike runtime exceptions / panics / etc. ADTs typically require handling immediately, exceptions are the opposite of that.

One of the bigger problems is that exceptions are slow. Thus the recommendation is not to use them in cases where the caller could branch on. A perfect example is a missing element in a remote system. An old api would throw some sort of a Element Not Found Exception. With the addition of Optional though you have a object that is easier to use, conveys your intention better, and doesn't have any of the performance drawbacks. I think what it comes down to is that when dealing with situations that might be handled by the caller you should use some sort of result object instead of a exception. This leaves exceptions only for the cases where the result cant be handled. In which case you dont need checked exceptions.

> A perfect example is a missing element in a remote system. An old api would throw some sort of a Element Not Found Exception.

Wait, if the example involves a remote system how can the Exception be the bottleneck? Even generating the completely optional stacktrace shouldn't take that much time.

Not as slow as many people think, especially with things like OmitStackTraceInFastThrow

OmitStackTraceInFastThrow has caused so many headaches in debugging production issues, and each time now the answer has been to just disable it. The real answer is to stop trying to abuse exceptions as a form of general control flow.

For some reason the most talked about "alternative" to exceptions seems to be "use optional". I would assume that this has the same debug issues as omitting the stack trace.

> I would assume that this has the same debug issues as omitting the stack trace.

I don't expect so. If I "forget to handle" an optional, I get an error at compile time pointing at the lines in question. If I forget to handle an exception with an omitted stack trace, IIUC, I am told at runtime that there's an error somewhere in my program. It's much easier to debug the former.

Exceptions are slow to throw, but they're meant to be exceptional so that's OK. Good implementations impose no overhead the rest of the time. This is not the case for return type based systems, where you can easily end up with an allocation that must be GCd later.

> I like checked exceptions. Yes, sometimes (especially in the oldest APIs when they were still figuring this stuff out), they were overused but mostly I think they encourage developers to really think about what happens in the failure case.

I agree and like them in theory, but in practice the only practical thing that can be done with an exception is to get away from this section of code as quickly as possible and get back up to a layer where the user/system can be notified of the failure in some way. Cases where you actually can gracefully handle an exception like a missing file tend to be something you should check and not rely on exceptions for anyway.

Reply on news.ycombinator.com