Hacker News Reader

Comment by flohofwoe | Hacker News Reader

The problem with exceptions isn't the syntax, but the hidden control flow (they are essentially a goto in disguise).

Error union return values make a lot more sense, the rest is just syntax sugar details (and that's where opinions differ I guess).

View on HN

Exceptions are not a form of gotos, they are both less powerful as they are structured and more powerful (as they are nonlocal). They desugar to continuations, but so does rust option type handling and ?. In fact they are pretty much equivalent.

I'm not terribly familiar with either language, but I don't see any particular difference between swift and rust error handling for example, swift will also mark fallible function calls with try, similarly to ? in rust.

For what is worth the author of the swift standard library believes that try is a mistake: as most functions can fail in practice it just becomes noise. It might be more useful to mark can't fail regions.

I think the nonlocal part is the scary part: it becomes very scary to figure out which parts of the code can fail and how, especially when failures can come from an arbitrarily deep call stack.

Maybe checked exceptions could be more useful to explicitly annotate allowed failures, but at the same time we all know how that's going in Java world.

If you consider the case where you call a function that throws an exception without you expecting it -- then the control flow will skip your code, and this is indeed not very structured, like a goto, and in fact less local than a goto.

I was actually wondering (in Zig, which has a per-statement "try" which is essentially the same as the ? in Rust) whether it also makes sense for whole blocks, which would look a lot like traditional try-catch block in languages with exceptions, e.g. instead of:

    try may_fail_1();
    try may_fail_2();
    try may_fail_3();

...this could be grouped into:

    try {
        may_fail_1();
        may_fail_2();
        may_fail_3();
    }

...but would behave exactly the same as the indiviual trys, if any function in the block returns with an error, that same error is passed up to the caller. But I guess that forcing individual trys makes you think harder about handling individual errors than just pushing the responsibility for error handling up the callstack.

Sure, but we have now (almost) gone full circle:).

When writing exception safe code, for me is more important to know which functions are guaranteed not to fail as they will be called in the commit path. Currently I just comment which operations are no-throw and otherwise assume that everything else can fail, but it would be nice to have the compiler tell me.

> for me is more important to know which functions are guaranteed not to fail as they will be called in the commit path

But Zig allows you to see immediately which functions are guaranteed not to fail because those functions's return types won't include an error type.

I've been pondering the same thing![0] Essentially, one would get (checked-)exception-like behavior, except that performance would be better, and whether a function can fail or not would still need to be declared explicitly in its return type.

> But I guess that forcing individual trys makes you think harder about handling individual errors than just pushing the responsibility for error handling up the callstack.

It probably does but it can also make code much harder to read if you have to check for errors after every other line. I'm a bit divided on this.

[0]: https://news.ycombinator.com/item?id=34856910

My two main languages are C# and Go.

* C# uses exceptions, and when I code it feels exactly the right choice

* Go uses error return values, and when I code it feels exactly the right choice

For some reason both feel very much ideal in use. Maybe it is because in each case the language syntax/ethos fits very well with the choice made, and so is frictionless when developing in the flow (and if used properly of course)? Maybe some other reason. Hey ho.

Reply on news.ycombinator.com