<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Dec 7, 2009 at 8:40 AM, Alexander Dunlap <span dir="ltr"><<a href="mailto:alexander.dunlap@gmail.com">alexander.dunlap@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>
><br>
><br>
> On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann<br>
> <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
>><br>
>> On Sun, 6 Dec 2009, Michael Snoyman wrote:<br>
>><br>
>>> I think there are plenty of examples like web servers. A text editor with<br>
>>> plugins? I<br>
>>> don't want to lose three hours worth of work just because some plugin<br>
>>> wasn't written<br>
>>> correctly. For many classes of programs, the distinction between error<br>
>>> and exception is<br>
>>> not only blurred, it's fully irrelevant. Harping on people every time<br>
>>> they use error in<br>
>>> the "wrong" sense seems unhelpful.<br>
>>><br>
>>> Hope my commenting on this subject doesn't become my own form of<br>
>>> *pedantry*.<br>
>><br>
>> In an earlier thread I have explained that one can consider a software<br>
>> architecture as divided into levels. What is an error in one level (text<br>
>> editor plugin, web server thread, operating system process) is an exception<br>
>> in the next higher level (text editor, web server, shell respectively). This<br>
>> doesn't reduce the importance to distinguish between errors and exceptions<br>
>> within one level. All approaches so far that I have seen in Haskell just mix<br>
>> exceptions and errors in an arbitrary way.<br>
><br>
> I think we can all appreciate why it would be a bad thing is we treat<br>
> exceptions as errors. For example, I don't want my program to crash on a<br>
> file not found.<br>
><br>
> On the other hand, what's so bad about treating errors as exceptions? If<br>
> instead of the program crashing on an array-out-of-bound or pattern-match it<br>
> throws an exception which can be caught, so what?<br>
><br>
> Michael<br>
><br>
<br>
</div></div>I think the key is in the difference between the user/client and<br>
programmer/developer. As Henning has been saying, these roles change<br>
as you go through the different levels of the program, but I see the<br>
difference between an error and an exception as this: when a problem<br>
is relevant to the user/client, it's an exception; when it is<br>
irrelevant to the user/client, it's an error. Suppose you were using<br>
some sort of exception framework and you got an error from a piece of<br>
library code (not the head function) saying that "head" had failed<br>
somewhere. This is absolutely meaningless to a client. It just means<br>
there's a problem in the library code; it doesn't mean anything is<br>
amiss in the client's space. The client basically has to throw the<br>
function out, whether by gracefully aborting the program, disabling<br>
the plugin, etc. Contrast this with an exception, such as "index not<br>
in map." This is entirely relevant to the client. All of the code<br>
knows exactly what is going on; it's just that the index isn't in the<br>
map. The client can recover from this by, say, substituting a default<br>
value, adding the index to the map, etc. Now, suppose the client knew<br>
a priori that the index was *supposed* to be in the map. Now this<br>
becomes an *error* to the *client* of the client, since there is a bug<br>
in the first client's code.<br>
<br>
I guess my point is that if I have a function, say, sort :: Ord a =><br>
[a] -> [a], and sort calls head somewhere in it, there's no point<br>
having "sort" throw an exception for "Prelude.head: []" since that<br>
means nothing to the client. It would make more sense to have an<br>
InternalError type that just says "OK, sorry client, I screwed up,<br>
just clean things up as best you can". If really were something that<br>
the client could have responded to, sort should have caught the head<br>
error inside the function definition and rethrown a different<br>
exception; say, SortEmptyListError if your sort function didn't work<br>
on empty lists (contrived example, sorry).<br>
<br>
Alex<br>
</blockquote></div>The WrapFailure typeclass in the the failure package makes this kind of library design fairly straightforward. I think you're making an argument for treating errors and exceptions the same way.<br>
<br>Michael<br></div>