[yorwba]

> 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.

[JoshuaAshton]

> 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

[maccard]

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.

[yorwba]

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

[JoshuaAshton]

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