Hacker News Reader

Comment by platz | Hacker News Reader

> the only problem with exception-based handling is the lack of explicitness - It's too easy to call functions without being aware of the set of possible errors.

i.e. checked-exceptions?

View on HN

Once you have checked exceptions, you're basically as verbose as the Error monad anyway. Except that instead of properly encoding it in the function result type, you have a separate mechanism, which is kinda sorta but not quite like a type. In Java, this manifests itself in things such as it being impossible to write a higher-order function that has a signature of "takes some function F, and can throw everything that F can throw, plus some E".

yep! there was a sort of epiphany for me, the first I wrote Java, from Python, when I realized that I can be sure that my code could handle anything the callee could throw at it.

There are still plenty of exceptions that are unchecked, i.e. subtypes of RuntimeException, which do not have to be declared on the callee. As well as people who think it's a good idea to throw instances of Exception and just tack a "throws Exception" on their methods.

Right — that's a failing of Java the language; not the concept of checked exceptions. At least one problem with Java's exception model that Zig does not have is that some exceptions are "unchecked."

The 'failing' of checked exceptions comes from essentially being forced to couple the type signatures of your methods' successful results with their error results. A more explicit way to do this is with Optional/Either types, and now you don't need the checked exceptions feature nor need to get people to remember to check for a global errno or some other data convention like an empty string / null. There's a lot of boilerplate though, just like with checked exceptions.

I prefer a more decoupled/late-binding approach to error handling; so far Common Lisp does it the best I've seen.[0] The key insight CL people had was that often in the face of an error, you need help from somewhere away from your local context to figure out how to resolve it, but then for many cases, you want to return back to where the error has occurred and take the resolution path with your local context. In other languages that automatically unwind the stack to the exception handler, it's too late.

[0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...

Zig has system-exit, which is strictly less useful than unchecked exceptions, so Zig certainly has the same problem.

Or just a compiler / IDE warning saying "X, and Y exceptions could be thrown here but are unhandled".

Then it's "checked" but catching is optional.

Yeah there are a lot of interesting things you can do if you design languages around an editor. Like complete, recursive type inference, so you don't have to annotate types on function signatures, but the editor can display them, which is very useful, or showing what exception can be thrown even if the language doesn't make it explicit. This works out great when the editor is available on the platform you need and working.

F# is a language this is a lot like this, and I've recently been unable to get the editor with these features working in Linux, and it makes it rather horrible. If you had to remote in to a server and use vim, it could be rather horrible, and so on.

If we can get something like the language server idea working, really well, on all platforms and supported by all editors, then designing languages around certain IDE assumptions would more often be a good idea I guess.

That's all very true, and it's sad that we haven't explored this space more.

It's a nice in-between something like a Smalltalk image-environment-IDE / Lisp Machine and a dumb IDE/editor that starts from source code and has to parse into AST into its own...

https://twitter.com/TeaDrivenDev/status/1054177017351024641

Reply on news.ycombinator.com