←back to thread

873 points belter | 1 comments | | HN request time: 0.214s | 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 #
rixed ◴[] No.42951257[source]
Yes, but then you have to handle every possible errors at every call point, and wrap all those you can't handle at the calling site into your own return type... This is well documented.

One should be cautious every time it feels like there is an obviously right way to do something that everybody fails to see :)

replies(1): >>42958017 #
lmm ◴[] No.42958017[source]
> Yes, but then you have to handle every possible errors at every call point, and wrap all those you can't handle at the calling site into your own return type... This is well documented.

What? No you don't. You can just propagate up the errors you can't handle with the types they come with.

replies(1): >>42960838 #
1. rixed ◴[] No.42960838[source]
What language are you using that will automatically infer this at compilation time?(*)

If I understand properly what you are suggesting, to make it work with my goto language (OCaml), I believe that I would have to make every function return a polymorphic variant for the error (aka technicaly equivalent to mandatory try blocks and boxed return types). The only time I had to deal with a library doing that it was not pleasant but it was too long ago for me to remember the details, probably related to complex compilation error messages.

(*) looking at your github, I guess Scala?