←back to thread

873 points belter | 3 comments | | HN request time: 2.122s | source
Show context
Terr_ ◴[] No.42946597[source]

> Java is a great language because it's boring [...] Types are assertions we make about the world

This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling.

In brief for non-Java folks: Checked Exceptions are a subset of all Exceptions. To throw them, they must be part of the function's type signature. To call that function, the caller code must make some kind of decision about what to do when that Checked Exception arrives. [0] It's basically another return type for the method, married with the conventions and flow-control features of Exceptions.

[0] Ex: Let it bubble up unimpeded, adding it to your own function signature; catch it and wrap it in your own exception with a type more appropriate to the layer of abstraction; catch it and log it; catch it and ignore it... Alas, many caught it and wrapped it in a generic RuntimeException.

replies(13): >>42946899 #>>42946979 #>>42947054 #>>42947147 #>>42947485 #>>42947568 #>>42948130 #>>42948153 #>>42948666 #>>42951688 #>>42952999 #>>42953957 #>>42984777 #
kaapipo ◴[] No.42948130[source]

Nah, I think having a monadic Maybe/Option type and first-class support for it is the correct solution. Exceptions are fundamentally flawed.

replies(1): >>42948382 #
rixed ◴[] No.42948382[source]

"None" to represent any type of failure sounds similarly fundamentally flawed too.

replies(1): >>42948635 #
lmm ◴[] No.42948635[source]

That's why you need not just an Either/Result type, but proper monads so that you can use the same functions with both.

replies(2): >>42951257 #>>42954801 #
valcron1000 ◴[] No.42954801[source]

As someone who worked with Haskell and Rust in production this is a nightmare: - All functions end up returnig `Either/Result` - Stack traces are gone - Exceptions and panics can still creep so it's not even "safer" - There is no composability of different result types, you need something like `Either<FooError | BarError | ..., A> which is not supported in most languages (I think Scala 3 and Ocaml have this feature), or you create a "general wrapper" like `SomeException` (Haskell) or use `anyhow` (Rust).

Today I write C# at my job and I could not be happier with the usage of exceptions.

replies(2): >>42958278 #>>42962712 #
1. tome ◴[] No.42962712[source]

Effect systems such as Bluefin (my own) and effectful allow you to have multiple possible exception effects in scope without having to cram them all into one type (with some sort of "variant" or "open sum" type). It's a very pleasant way to work!

replies(2): >>42964771 #>>42967550 #
2. nsm ◴[] No.42964771[source]

Aren't checked exceptions the same as effect systems in the narrow case of error handling?

3. valcron1000 ◴[] No.42967550[source]

I haven't had the time to play with Bluefin (I'll get to it eventually!) but I did try out effectful. In the later I've only used the `Fail` effect since most of the time I just want to bail out when some invariant is broken. In my experience these fine-grained errors don't provide much value in practice but I understand the appeal for some.