> But even if they did that, the server could be down, the user's internet could be down, or there could be a typo in the URL that makes it unreachable, even if the URL itself is still valid.
That doesn't contradict my statement. In all those cases, the code cannot continue to do anymore meaningful work. Handling the parsing error just handles that one situation.
> I have written tons of code where I've caught exceptions and then continued to do meaningful work.
But the code that threw the exception could not continue to do meaningful work. You can the catch the exception and do something else or maybe try the same operation again. But either way, the original code could not and did not continue. In general, you have to reach higher up in the call stack before you find a spot where you can something different or retry. This is why exceptions are useful.
> That doesn't contradict my statement. In all those cases, the code cannot continue to do meaningful work. Just fixing the parsing error just takes one such condition out. I never claimed otherwise.
If you continued reading to the next paragraph, I presented an option for how the code could continue doing more work.
> But the code that threw the exception could not continue to do meaningful work. You can the catch the exception and do something else or maybe try the same operation again. But either way, the original code could not continue.
But that's not what you said! Or at least what you said was ambiguous. "The code can no longer do any meaningful work." What code? I interpreted that as "all the following code", which feels like an entirely reasonable interpretation to me. I feel like this just proves the author's point -- it's ambiguous!
Ok, so then what you really mean is: "the code that threw the exception can no longer do any meaningful work". Ok, sure, that's true, but I don't think that's a useful definition. I suppose perhaps it's useful if you're explaining it to a non-programmer who is unlikely to need any more information (arguably, you shouldn't bring up exceptions to a non-programmer; just tell them "the code encountered an error and couldn't continue anymore"). But if you're talking to a programmer, or, rather, teaching a new programmer, that definition is entirely insufficient. Because from there, you need to talk about why the way to signal that inability is to use an exception. You need to talk about other ways to signal that, and what the trade offs are. You need to dig deeper. At best your definition is only the very very very beginning of a longer conversation; it doesn't give enough information on its own.
> What code? I interpreted that as "all the following code", which feels like an entirely reasonable interpretation to me.
It is. As long as you define "all following code" as the code that would execute from that point forward. If you define "following" as simply the code in the rest of the file then doesn't really make sense in this context I don't why you would mean that.
Obviously the existence of catch statements allows the program to continue from that point but none of that code is following from where the error was (unless you call it again).
> At best your definition is only the very very very beginning of a longer conversation; it doesn't give enough information on its own.
If you want me to write an essay on this, I have actually already written one. But I still think this definition is a good one. It is simple but that's what makes it useful. The entire subject of error handling cannot be distilled into a single sentence definition and that is not what I intended to do.
That doesn't contradict my statement. In all those cases, the code cannot continue to do anymore meaningful work. Handling the parsing error just handles that one situation.
> I have written tons of code where I've caught exceptions and then continued to do meaningful work.
But the code that threw the exception could not continue to do meaningful work. You can the catch the exception and do something else or maybe try the same operation again. But either way, the original code could not and did not continue. In general, you have to reach higher up in the call stack before you find a spot where you can something different or retry. This is why exceptions are useful.