> I think "an exception is when code can no longer do any meaningful work" is a great definition,
I'm not so sure: that definition glibly turns every error or failure into an exception.
Is "Failure to Open File" really an exceptional condition? This is a common condition that is basically a business rule[1].
Think about the "saving a file" action. There's errors that you expect to happen, and have to provide code to handle (like, permission denied, path exists and is a directory, etc), and exceptional conditions that should never have arisen in a program which no sane person would try to handle (Out of memory, disk write errors, etc).
In both cases, no progress can be made and the callee has to return to the caller. But, in the error cases a well-written program will defend against the errors in a meaningful manner, whereas in the exceptional cases there is literally no point in putting in code to handle those cases.
Just some food for thought - I'm not particularly married to these definitions.
[1] Here are some hypothetical options for failing to open a file:
1. If the file doesn't exist, prompt the user asking if it must be created, and proceed only if "Yes" is received, return to caller if "No" is received.
2. If the file is a directory, display a fatal error message and return to caller.
3. If permission is denied, display an ACL error message and return to caller.
I have a desktop application with a single error handler at its event loop. All that handler does is show the exception message in a messagebox and then the event loop resumes. This application has a "save file" option.
In this application it doesn't matter if the permission is denied, the path exists and is a directory, it was a network share that went away, or a disk write error, or out of memory, or a bug. If I press "Save" and the exception occurs, I can read the message and correct the problem if possible, and then just press Save again. It is incredibly robust and has effectively no error handling.
Of course, that doesn't handle all the cases that you describe. For example, for your case #1 I think that isn't a case that no more meaningful work can be done and isn't an error. Instead, you're just asking a question and then proceeding or not based on the answer.
I'm not so sure: that definition glibly turns every error or failure into an exception.
Is "Failure to Open File" really an exceptional condition? This is a common condition that is basically a business rule[1].
Think about the "saving a file" action. There's errors that you expect to happen, and have to provide code to handle (like, permission denied, path exists and is a directory, etc), and exceptional conditions that should never have arisen in a program which no sane person would try to handle (Out of memory, disk write errors, etc).
In both cases, no progress can be made and the callee has to return to the caller. But, in the error cases a well-written program will defend against the errors in a meaningful manner, whereas in the exceptional cases there is literally no point in putting in code to handle those cases.
Just some food for thought - I'm not particularly married to these definitions.
[1] Here are some hypothetical options for failing to open a file:
1. If the file doesn't exist, prompt the user asking if it must be created, and proceed only if "Yes" is received, return to caller if "No" is received.
2. If the file is a directory, display a fatal error message and return to caller.
3. If permission is denied, display an ACL error message and return to caller.