Hacker News Reader

Comment by codethief | Hacker News Reader

> Exceptions have very high performance costs (equivalent to a longjmp which is very slow)

Could you elaborate on why they are so slow, compared to passing around/returning error objects explicitly?

They are slow because you need to restore context from an unknown/unpredictable place in the code, you have a table lookup (from a very cold table) to get the next program counter value, and you have to save and restore register values, while the callstack and the calling convention handle all of that complexity for you if you don't break the natural flow of the program.

But couldn't one implement exceptions internally by returning error codes? Yes, this would change the ABI but as long as we're not talking about the interface of a library, i.e. are not leaving the realms of our source code, this should be ok, shouldn't it?

In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs.

EDIT: I just realized my suggestion wouldn't exactly be equivalent to exceptions, in the sense that it wouldn't give stack traces but error return traces, like in Zig:

https://ziglang.org/documentation/master/#Error-Return-Trace...

> In a sense, try/catch would then just be syntactic sugar that frees you from manually checking for errors after every single function call. Instead, you just handle them in bulk in a catch block, potentially a couple stack frames further upstairs.

Here someone else had the same idea: https://news.ycombinator.com/item?id=34846550

Reply on news.ycombinator.com