4 ms·

> Clarification please--are you suggesting the programmer can anticipate all reasonably likely error conditions and implement handlers for each? Absolutely, in

> Clarification please--are you suggesting the programmer can anticipate all reasonably likely error conditions and implement handlers for each? Absolutely, insofar as it is possible for a programmer to write their application in one of the several existing programming languages that can guarantee at compile time that there is no undefined behavior / exceptions / crashes / memory corruption. This concept is sometimes referred to as a "total function": a function that is defined for all possible input values, and in a language for which there is no way to invoke that function on an input not in its statically-declared domain. Now, I'm not saying this is possible for all programs, particularly for certain kinds of I/O, but with a reasonable amount of error handling code and robust interfaces between that I/O device and your code, it's usually possible to get pretty close to perfection there too. I'm also not saying it's easy. But I think this is precisely the kind of "hard" the software engineering industry needs more of right now; and languages like Rust and Zig and even Spark (Ada verifier) are a wonderfully refreshing move in that direction. Note: Not all of these languages I mention are 100% perfectionist either! What's important is they move significantly closer to perfection, and away from this 'cowboy coding' mentality of not really caring about errors/exceptions until they bite you.

sk5t 8y ago
Really puzzled that you have conflated exceptions ("'x' went wrong, here's the stack") with undefined behavior, crashes and memory corruption. It seems as though you're describing how the world ought to be, and maybe could be, for the writing of pure functions, procedures with provably no side effects, and the like. Well, OK. However, imagine that you're writing a few bytes to disk. Maybe the device runs out of space halfway through the write, the filesystem was mounted readonly, or the filesystem doesn't like the filename you asked for due to length or case-insensitive overlap with an existing name, or the controller driver glitches out, or permissions are wrong, etc., etc. You cannot anticipate all of these and implement recovery, aside from informing the caller what went wrong, and giving an opportunity to somehow correct the problem elsewhere and retry. Well now you're in the business of not really recovering from the fault, but instead doing something the same or nearly the same as raising an exception and printing the stacktrace. TBH I have misgivings about even writing up that last paragraph because the alternatives really strain credibility.
- kelnos 8y ago
  I don't think the parent was suggesting that there's anything wrong with what you wrote in that paragraph. At least IMO that counts as handling the error, vs. just doing nothing and assuming everything is ok. If you have to kick it back to the user and say "sorry, XYZ happened, and there's nothing I can do about it", that absolutely counts as handling the error. Not handling it would be just assuming the file got written properly to disk and then later having to deal with corrupt data.
dnautics 8y ago
You could also argue that relying on "total functions" is an antipattern because it doesn't account for "undefined behavior / exceptions / crashes / memory corruption" and leads programmers to overreliance on the compiler. We can throw race conditions and deadlocks in there too, since very often it will be difficult for a compiler to detect those at compile time. A PL that gracefully handles programming errors as well as exceptions, memory corruptions, etc, emitting a logged problem and continue to chug along will let the programmer decide how bad an error is, with high uptime, and make a business decision about whether or not it's worth fixing at the time.

sk5t 8y ago

Really puzzled that you have conflated exceptions ("'x' went wrong, here's the stack") with undefined behavior, crashes and memory corruption. It seems as though you're describing how the world ought to be, and maybe could be, for the writing of pure functions, procedures with provably no side effects, and the like. Well, OK. However, imagine that you're writing a few bytes to disk. Maybe the device runs out of space halfway through the write, the filesystem was mounted readonly, or the filesystem doesn't like the filename you asked for due to length or case-insensitive overlap with an existing name, or the controller driver glitches out, or permissions are wrong, etc., etc. You cannot anticipate all of these and implement recovery, aside from informing the caller what went wrong, and giving an opportunity to somehow correct the problem elsewhere and retry. Well now you're in the business of not really recovering from the fault, but instead doing something the same or nearly the same as raising an exception and printing the stacktrace. TBH I have misgivings about even writing up that last paragraph because the alternatives really strain credibility.

kelnos 8y ago
I don't think the parent was suggesting that there's anything wrong with what you wrote in that paragraph. At least IMO that counts as handling the error, vs. just doing nothing and assuming everything is ok. If you have to kick it back to the user and say "sorry, XYZ happened, and there's nothing I can do about it", that absolutely counts as handling the error. Not handling it would be just assuming the file got written properly to disk and then later having to deal with corrupt data.

dnautics 8y ago

You could also argue that relying on "total functions" is an antipattern because it doesn't account for "undefined behavior / exceptions / crashes / memory corruption" and leads programmers to overreliance on the compiler. We can throw race conditions and deadlocks in there too, since very often it will be difficult for a compiler to detect those at compile time. A PL that gracefully handles programming errors as well as exceptions, memory corruptions, etc, emitting a logged problem and continue to chug along will let the programmer decide how bad an error is, with high uptime, and make a business decision about whether or not it's worth fixing at the time.