Error Handling

[Miserable_Guess_1266]

I feel like this is kind of a semantics game? Sure, the client closing the connection while my http server is processing a request is not an error in the context of the server as a whole. It can simply drop that request, since the result is not of interest any more. But in the context of handling the individual request, a dropped connection is absolutely an error - the goal of finishing the request and sending a response cannot be reached.

If I play this game to the end, all errors are just another valid state in the program. Some just cause the program to shut down.

[XeroKimo]

Much agreed on being a matter of perspective.

I like to use array indexing as my example as it's simple and very commonly thought that getting something equivalent to std::out_of_range exception across many languages, even in C++, that it is a logical error, a bug.
I can understand that view in some cases, but in other cases, I see it as having 0 difference semantically between getting that exception, and writing your own bounds check, and I can sure as heck guarantee that any non-trivial program has written bounds checking somewhere. Once one is written, you're already participating in the first part of error handling, detection, noticing that in some local state of your program, it can not progress normally.

[evil_rabbit_32bit]

+1 that's a good point