Hacker News Reader

Comment by wiseowise | Hacker News Reader

> In Zig, the compiler forces you to handle exceptions (errors) at the callsite, so you can see from looking at function calls at the callsite what the potential control flow looks like.

Damn, if only Java had something like that. Where you can see from function declaration whether it can throw something. Like if you could check exception. We could call it checked exceptions. And community would certainly like them.

View on HN

Java exception specifications are annoying for two reasons. Firstly, there's no syntactic sugar to easily rewrap and propagate. Secondly, there is no way to generalize your error handling logic - i.e. for one component to say "I want to use something that implements this interface, and I don't care what errors it throws, but I do want to propagate them all". Zig doesn't have either problem.

Java has @SneakyThrows. Fight me.

Java has a whole system of annotations that seems designed to make it impossible to figure out what code will actually be run, apparently designed by someone who thought lisp macros were too explicit.

Which is a hack that amounts to throwing one's hands up and declaring, "we couldn't make it work properly".

Who couldn't make it work properly, the language designer, the stdlib writers or the Java programmers?

There is no way to make e.g. InterruptedException "work properly" as a checked exception since there is nothing intelligent one can do about it that's specific to this exception class. Rewrapping as RuntimeEx is just as much weaseling out but using more code and messing up stack trace for no good reason.

Also, thanks for answering my request for a fight. Winter is boring.

The language designers, because they wanted to have checked exceptions without the complexity of genericizing them.

Exceptions that aren't meant to be handled really shouldn't be exceptions in the first place, but that's a separate design issue.

Yeah but in Zig there is flexibility how you want to handle the error opposed to Java. You don't need to rewrap everything in RuntimeException and error sets allows to specify extended set of errors without much boilerplate.

That still doesn't show you at the call site.

This is why I will never stop trying to insert throws declarations into code I write. For some reason, Java developers seem to like hiding the fact their function can throw exceptions.

The syntax problem gets mentioned a lot ("we'll just end up catching and rethrowing it anyway") but at that point you can just add throws to the calling method.

I don’t think you can ever argue that a small (and only non-runtime exception, right?) signature at the top of the function makes it easy to see what lines throw.

Even if a function is small, each and every line could be the thrower and not allow the rest to execute.

Reply on news.ycombinator.com