Hacker News Reader

Comment by JoshuaAshton | Hacker News Reader

> That's because you're inexperienced.

That's fairly rude to the guy, and doesn't make your point any stronger.

I've worked with exceptions before, it leads to try/catch spaghetti code.

You can't possibly know instantly all the exceptions to handle for a function (given it calls other functions w/ exceptions), whereas, if it returns a fixed bunch of error codes, then you can know why that specific function failed and handle appropriately.

Doesn't help that (language) exceptions typically have awful codegen.

There's a reason nobody uses them in game-dev.

View on HN

> You can't possibly know instantly all the exceptions to handle for a function (given it calls other functions w/ exceptions),

You also can't possibly know all error codes to handle for a function if it calls other functions returning error codes, unless a type system enforces that for you. In which case you should compare to a language where the type system enforces that all exceptions are handled.

> You also can't possibly know all error codes to handle for a function if it calls other functions returning error codes

You aren't using error codes or documenting correctly. You get a choice whether the error propogates upstream

Exceptions can be documented just as well, and you have the same choice whether the error propagates upstream, only the default is different.

The default idea behind exceptions is silly and as I stated before, they typically get generated to some horrific code

I can make the same argument for exceptions - You're not documenting correctly. You also have the choice to ignore and fail with exceptions.

Example: you have a method which requests a file from disk, but it fails to load for some reason. With error codes, you force all callers of your resource loader to explicitly handle the failure case at the point of failure, or you lose all context on the error. If you just bubble the error up, you're manually doing exceptions.

With exceptions, the code that requests a file can assume it succeeds if it doesn't have enough context to handle the erorr, and you can handle at a higher level and still know what happened.

I might be misunderstanding, but doesn't this

> You can't possibly know instantly all the exceptions to handle for a function (given it calls other functions w/ exceptions), whereas, if it returns a fixed bunch of error codes, then you can know why that specific function failed and handle appropriately.

presume that, despite not being able to know all exceptions to handle in advance, you somehow have knowledge of all error conditions in the event that you're using error codes?

> presume that, despite not being able to know all exceptions to handle in advance, you somehow have knowledge of all error conditions in the event that you're using error codes?

I guess that it is indeed the case. If you call one function, you can read the documentation of said function and read about its return values, including error codes. This specification cannot not change if one of the libraries nested deep within this function is replaced. However, with exceptions, if you use a new implementation of a deeply nested function it may raise a new exception that nobody was aware of at the time of writing the outermost functions.

Usually documentation tends to have this, or you can look at the function and immediately know what it will return, whereas with exceptions any passthrough errors are transparent.

> You can't possibly know instantly all the exceptions to handle for a function

And you never should. That indeed is horrible design.

What you do need is a separation between 'exceptions that cause hard failure' v.s. 'exceptions that can lead to soft restarts'.

You can easily separate them using common sense just looking at where your interface is located.

Reply on news.ycombinator.com