[Haskell-cafe] Exception handling when using STUArray

[Donn Cave]

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 at avvanta.com