On Mar 9, 2008, at 1:07 PM, Henning Thielemann wrote:
Errors are programming errors and must be fixed as Denis explained. Thus there is no need for a complex system of handling these situations at run-time. The program error might be unexpected but it isn't the fault of the user or of the context the program runs in but of the fault of the programmer. The program may report "bug detected, send an e-mail to the author" but eventually it should quit (at least the buggy thread) before worse things happen. This is possible in Haskell but should not be mixed up with handling of exceptions like "non-existing file".
I am not sure I see the difference in principle that you see. An exception is, for me, any state that isn't properly accounted for in its immediate context. openFile could return 'Maybe Handle', but it doesn't, so the context demands a Handle or an exception. 'head' demands data with at least one element, or an exception. Now, we do have the means to validate the latter assumption, and not the former - I can check that a file exists, but can't usually guarantee that it will exist at the instant I try to open it. Is that where you find the distinction?
How precisely would you handle IndexError if it would be an exception and not just an error?
Well, to take a hypothetical example ... I have never looked into JPEG image decoding, but suppose that it's moderately complicated and further that it involves array indexing at some point, and I have written a web browser that needs to decode and display images. Maybe one in ten thousand JPEG images will be invalid for some reason, in a way that leads to an index beyond the bounds of its sequence. Because we have the data at hand, we can certainly validate indices vs. bounds and avoid an index error. Then we need an Either or Maybe or some such thing to express that, and some way to propagate the issue up to the top of the image renderer. Whereupon it will refuse to render the image and will put its broken image icon in its place. Or, I can just write the JPEG decoding algorithm, and catch index errors at that same place, and refuse to render the image etc.. To me, this doesn't pose any moral problem, and the code is bound to be clearer and more expressive of its core intention, than if it were burdened with layer upon layer of Rights and Justs to defend against a problem that has no real solution and may never even occur. If the image I'm supposed to decode isn't actually there when I try to open the file, then I'll display the very same icon in its place. We want the same thing to happen, whatever the problem with the image: display the broken image icon, and go on to render the rest of the page. Now if we want to be philosophical about it, all of these problems don't have to be with the image - maybe it's a variant JPEG type that I didn't know about, or even just my coding error that happened to escape testing. The web browser should carry on regardless, however, so the implementation shouldn't be sensitive to these philosophical distinctions. Donn Cave, donn@avvanta.com