Why exceptions for error handling is so important

[via Digitalmars-d]

On Wednesday, 14 January 2015 at 17:45:28 UTC, deadalnix wrote:
> On Wednesday, 14 January 2015 at 11:17:52 UTC, Marc Schütz 
> wrote:
>> Your claims:
>>
>> - Exceptions are for "I have no idea what to do about this" 
>> situations.
>> - "exceptions for control flow [...] makes for very 
>> unreadable/unmaintainable code"
>>
>> Ola's answer directly addresses these claims and provides a 
>> counter-example (in the last paragraph), which I happen to 
>> agree with.
>>
>> => Not a strawman.
>
> Being precise is important.
>
> The example presented (ie throwing a exception signaling a http 
> code) is a good one and never contradict what I said.
>
> It is an example "I have no idea what to do about this". The 
> code throwing the exception is faced with a situation where it 
> cannot continue (assuming this code is expected to generate a 
> webpage or something like that) but at the same time, is not in 
> a position to perform the custom http so it is bailing out. It 
> is signaling to higher level "I would have liked to return this 
> http code, but have no idea how to do so and so I'm giving up."
>
> Now I see how you can consider this as a control flow, but it 
> is vastly different from usual control flow (loops, branches, 
> calls, ...). It is vastly different. You have no idea where you 
> send your program into. In fact, you may not even be in in the 
> framework that can make sens of this exception, you have no 
> idea. Conversely, the framwork that is catching this exception 
> have no idea where it came from, and it do not care either. It 
> simply know that the page failed to render and that instead it 
> should return a specific error code.

Indeed I was assuming that the code handling the HTTP request 
("controller" in MVC terms) is aware of the framework, because I 
don't think it's common to have exchangeable server frameworks 
for any given web application. Given that, the use of exceptions 
becomes part of the framework's API. Furthermore, the code also 
has a very clear idea of how to handle the situation, namely 
instructing the framework to return a specific error code. That 
is not giving up, in my eyes, but actually the opposite, to 
answer a specific request (e.g. "GET /non-existant-file.txt") 
with the response prescribed by the protocal (e.g. "404 Not 
found"). It could just as well have called a helper 
`respondWith404()` provided by the framework to set a flag 
somewhere and return to the framework in order to it act 
accordingly. It's just that the mechanism of using an exception 
seems more convenient (but of course, de gustibus...).

Now, for a more generic library, you are right that using 
exceptions in this way is not a good idea. The crucial difference 
is IMO that in an MVC framework the application code is the one 
down the stack, while in many other applications it is further up 
the stack. Therefore, the use of exceptions (which always 
propagate upwards) have to be assessed differently.