22

I'm just curious, is there any other languages besides Java that uses checked exceptions ?

I did try to find information about this but couldn't find any answers.

Christiaan
  • 639
  • 1
  • 8
  • 18

3 Answers3

6

The reason you couldn't find information on any other languages using checked exceptions is they learned from Java's mistake.

EDIT: So to clarify a little more checked exceptions were entirely a Java thing that in theory sounded like a really great idea, but in practice actually create a tight coupling between the consuming function and the function being consumed. It also makes it more tedious to handle an exception where it can be handled. Instead you have to catch and re-throw in every function in between where the exception was thrown and where it can actually be handled. I could rewrite it all here but I think this post does a magnificent job of explaining why checked exceptions are really not a good idea.

https://blog.philipphauer.de/checked-exceptions-are-evil/

HopAlongPolly
  • 1,347
  • 1
  • 20
  • 48
  • 2
    This answer unfortunately has a lot of bias from the author and some misconceptions, for example "you have to catch and re-throw in every function in between where the exception was thrown and where it can actually be handled" is simply untrue. – john16384 Nov 20 '21 at 17:10
  • @john16384 you are absolutely correct you also have the option of redeclaring it in the calling method signature. – Christo Jul 29 '23 at 15:58
4

Checked exceptions are not a common feature in mainstream languages due to bad experiences with them in Java. However, Java is not the only language that implements them, and just because Java's implementation was faulty does not mean that they are a bad feature in general.

Nim has checked exceptions.

Checked exceptions have been implemented as a Purescript library.

Checked exceptions can be implemented in Koka by making a custom defined effect for it.

Some common issues with checked exceptions in Java can be handled with better design.

Propogation of "throws" clauses in type signatures leading to potentially a lot of refactoring due to having to update method signatures can be solved via complete type inference. Haskell has a nice way of solving this for type classes (which propogate in the same way checked exceptions do in type signatures -- and can also be used to implement typed exceptions) with partial type signatures -- essentially leaving arbitrary parts of the type "blank" for the compiler to infer.

Issues with higher order functions/lambdas can be resolved via polymorphism/generics. In languages that implement checked exceptions via an effect system (like Koka) -- effect polymorphism is a particularly nice way to solve the problem.

Haskell, Koka, Purescript, and Nim are all highly functional languages that often make use of lambdas and higher order functions, and they don't have Java's issues with checked exceptions.

Nathan BeDell
  • 2,263
  • 1
  • 14
  • 25
0

One could argue that Go has checked exceptions, only with less syntax sugar to deal with them than e.g. Java.

resp, err := http.Get("https://www.google.com")
if err != nil {
   log.Fatal(err)
}

You have to check that exception right there or it's gone. Ironically, the one syntax sugar Go has over Java regarding exceptions is that it's much easier to simply ignore them (in Java you'd have to wrap the whole thing in a try and then do nothing in catch whilst in Go you just skip the if).

Gregor Petrin
  • 2,891
  • 1
  • 20
  • 24
  • I don't think a return value that indicates an error condition qualifies as an exception in a way that's meaningful for this question. One common feature of exceptions that is expected is that their production/consuming is non-local: the code handling the exception is not necessarily the one invoking the throwing method in the first place, but could be further down the call stack. That's not true in this case (unless each method explicitly has the same `err` return value and passes it down, but then that's manually implemented). – Joachim Sauer Jul 11 '23 at 11:58