Re: [Haskell-cafe] New Hackage category: Error Handling
On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman mich...@snoyman.com wrote: On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 6 Dec 2009, Michael Snoyman wrote: I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? Michael I think the key is in the difference between the user/client and programmer/developer. As Henning has been saying, these roles change as you go through the different levels of the program, but I see the difference between an error and an exception as this: when a problem is relevant to the user/client, it's an exception; when it is irrelevant to the user/client, it's an error. Suppose you were using some sort of exception framework and you got an error from a piece of library code (not the head function) saying that head had failed somewhere. This is absolutely meaningless to a client. It just means there's a problem in the library code; it doesn't mean anything is amiss in the client's space. The client basically has to throw the function out, whether by gracefully aborting the program, disabling the plugin, etc. Contrast this with an exception, such as index not in map. This is entirely relevant to the client. All of the code knows exactly what is going on; it's just that the index isn't in the map. The client can recover from this by, say, substituting a default value, adding the index to the map, etc. Now, suppose the client knew a priori that the index was *supposed* to be in the map. Now this becomes an *error* to the *client* of the client, since there is a bug in the first client's code. I guess my point is that if I have a function, say, sort :: Ord a = [a] - [a], and sort calls head somewhere in it, there's no point having sort throw an exception for Prelude.head: [] since that means nothing to the client. It would make more sense to have an InternalError type that just says OK, sorry client, I screwed up, just clean things up as best you can. If really were something that the client could have responded to, sort should have caught the head error inside the function definition and rethrown a different exception; say, SortEmptyListError if your sort function didn't work on empty lists (contrived example, sorry). Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sun, Dec 6, 2009 at 10:40 PM, Alexander Dunlap alexander.dun...@gmail.com wrote: On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman mich...@snoyman.com wrote: On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 6 Dec 2009, Michael Snoyman wrote: I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? Michael I think the key is in the difference between the user/client and programmer/developer. As Henning has been saying, these roles change as you go through the different levels of the program, but I see the difference between an error and an exception as this: when a problem is relevant to the user/client, it's an exception; when it is irrelevant to the user/client, it's an error. Suppose you were using some sort of exception framework and you got an error from a piece of library code (not the head function) saying that head had failed somewhere. This is absolutely meaningless to a client. It just means there's a problem in the library code; it doesn't mean anything is amiss in the client's space. The client basically has to throw the function out, whether by gracefully aborting the program, disabling the plugin, etc. Contrast this with an exception, such as index not in map. This is entirely relevant to the client. All of the code knows exactly what is going on; it's just that the index isn't in the map. The client can recover from this by, say, substituting a default value, adding the index to the map, etc. Now, suppose the client knew a priori that the index was *supposed* to be in the map. Now this becomes an *error* to the *client* of the client, since there is a bug in the first client's code. I guess my point is that if I have a function, say, sort :: Ord a = [a] - [a], and sort calls head somewhere in it, there's no point having sort throw an exception for Prelude.head: [] since that means nothing to the client. It would make more sense to have an InternalError type that just says OK, sorry client, I screwed up, just clean things up as best you can. If really were something that the client could have responded to, sort should have caught the head error inside the function definition and rethrown a different exception; say, SortEmptyListError if your sort function didn't work on empty lists (contrived example, sorry). Alex (Sorry for replying to myself.) This is, of course, assuming that a non-empty list was not an invariant of the sort function, in which case it would be a programming error on the part of the client that called sort if that happened. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Mon, Dec 7, 2009 at 8:40 AM, Alexander Dunlap alexander.dun...@gmail.com wrote: On Sat, Dec 5, 2009 at 3:00 PM, Michael Snoyman mich...@snoyman.com wrote: On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 6 Dec 2009, Michael Snoyman wrote: I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? Michael I think the key is in the difference between the user/client and programmer/developer. As Henning has been saying, these roles change as you go through the different levels of the program, but I see the difference between an error and an exception as this: when a problem is relevant to the user/client, it's an exception; when it is irrelevant to the user/client, it's an error. Suppose you were using some sort of exception framework and you got an error from a piece of library code (not the head function) saying that head had failed somewhere. This is absolutely meaningless to a client. It just means there's a problem in the library code; it doesn't mean anything is amiss in the client's space. The client basically has to throw the function out, whether by gracefully aborting the program, disabling the plugin, etc. Contrast this with an exception, such as index not in map. This is entirely relevant to the client. All of the code knows exactly what is going on; it's just that the index isn't in the map. The client can recover from this by, say, substituting a default value, adding the index to the map, etc. Now, suppose the client knew a priori that the index was *supposed* to be in the map. Now this becomes an *error* to the *client* of the client, since there is a bug in the first client's code. I guess my point is that if I have a function, say, sort :: Ord a = [a] - [a], and sort calls head somewhere in it, there's no point having sort throw an exception for Prelude.head: [] since that means nothing to the client. It would make more sense to have an InternalError type that just says OK, sorry client, I screwed up, just clean things up as best you can. If really were something that the client could have responded to, sort should have caught the head error inside the function definition and rethrown a different exception; say, SortEmptyListError if your sort function didn't work on empty lists (contrived example, sorry). Alex 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. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
Careful Gregory, you've hit a hot-button issue: you have dared to refer to exceptions as errors! For the record, I find this pedanticism misplaced, as the line between the two is rather blurry. Nonetheless, for control-monad-failure and attempt, we purposely refer to the whole slew of things not succeeding as failures. Not to be confused with public enemy number 2 of Haskell users: the fail function. /tongue-in-cheek Michael On Fri, Dec 4, 2009 at 5:57 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: Gregory Crosswhite schrieb: When I uploaded my new package, error-message, I also went ahead and created a new category: Error Handling. Error handling is the same as debugging for you? I hope it is not intended for generating further confusion about exception handling and debugging (= help programmers to analyse errors). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: For the record, I find this pedanticism misplaced, ... I think you'll find that's pedantry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sat, Dec 5, 2009 at 7:41 PM, Ross Paterson r...@soi.city.ac.uk wrote: On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: For the record, I find this pedanticism misplaced, ... I think you'll find that's pedantry. Hoped someone would comment exactly that ;). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sat, 5 Dec 2009, Michael Snoyman wrote: On Sat, Dec 5, 2009 at 7:41 PM, Ross Paterson r...@soi.city.ac.uk wrote: On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: For the record, I find this pedanticism misplaced, ... I think you'll find that's pedantry. Hoped someone would comment exactly that ;). :-) Nonetheless: Although there might be cases, where it is not immediately clear what is error and what is exception (not to mention, that different people prefer to use the words for the corresponding concepts in a different way, if they would do so consistently, it would be ok), in most cases it is clear. Have you ever tried to handle an array index out of range situation at run-time? I think, it cannot be sensibly handled by the program automatically. Thus there is no other way than terminating the program. Thus I'd call this situation an error not an exception. Of course, people like to throw in here a web server as counterexample. So to speak: With respect to exceptions web servers are an exception. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sun, Dec 6, 2009 at 12:17 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sat, 5 Dec 2009, Michael Snoyman wrote: On Sat, Dec 5, 2009 at 7:41 PM, Ross Paterson r...@soi.city.ac.uk wrote: On Sat, Dec 05, 2009 at 05:52:11PM +0200, Michael Snoyman wrote: For the record, I find this pedanticism misplaced, ... I think you'll find that's pedantry. Hoped someone would comment exactly that ;). :-) Nonetheless: Although there might be cases, where it is not immediately clear what is error and what is exception (not to mention, that different people prefer to use the words for the corresponding concepts in a different way, if they would do so consistently, it would be ok), in most cases it is clear. Have you ever tried to handle an array index out of range situation at run-time? I think, it cannot be sensibly handled by the program automatically. Thus there is no other way than terminating the program. Thus I'd call this situation an error not an exception. Of course, people like to throw in here a web server as counterexample. So to speak: With respect to exceptions web servers are an exception. I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sun, 6 Dec 2009, Michael Snoyman wrote: I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sun, Dec 6, 2009 at 12:55 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sun, 6 Dec 2009, Michael Snoyman wrote: I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Dec 5, 2009, at 3:00 PM, Michael Snoyman wrote: I think we can all appreciate why it would be a bad thing is we treat exceptions as errors. For example, I don't want my program to crash on a file not found. On the other hand, what's so bad about treating errors as exceptions? If instead of the program crashing on an array-out-of-bound or pattern-match it throws an exception which can be caught, so what? As I understand it, an error is a problem which aborts a computation and an exception is a problem that simply needs to be dealt with before the computation can continue. You are correct that there should be as few irrecoverable errors as possible in an application. In particular, if we think of an application as being a whole bunch of sub-computation tied together into a larger computation, then in a sense what we want is for no the failure of no sub-computation to cause the whole application-wide computation to fail. This, however, does not mean that there will be no circumstances under which any sub-computation fails, such as in the case of discovering in the middle of leading a file that it is irrecoverably corrupt. When these circumstances occur, one has an error and not an exception because there is no way to finish loading the file. However, at a higher lever, the sub-computation of loading the file was not necessary for the application to keep running, and so an error in the sub-computation becomes merely an exception when propagated up to the application level. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
On Sat, 5 Dec 2009, Henning Thielemann wrote: On Sun, 6 Dec 2009, Michael Snoyman wrote: I think there are plenty of examples like web servers. A text editor with plugins? I don't want to lose three hours worth of work just because some plugin wasn't written correctly. For many classes of programs, the distinction between error and exception is not only blurred, it's fully irrelevant. Harping on people every time they use error in the wrong sense seems unhelpful. Hope my commenting on this subject doesn't become my own form of *pedantry*. In an earlier thread I have explained that one can consider a software architecture as divided into levels. What is an error in one level (text editor plugin, web server thread, operating system process) is an exception in the next higher level (text editor, web server, shell respectively). This doesn't reduce the importance to distinguish between errors and exceptions within one level. All approaches so far that I have seen in Haskell just mix exceptions and errors in an arbitrary way. I have just written more details on this topic: http://www.haskell.org/haskellwiki/Error_vs._Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Hackage category: Error Handling
Gregory Crosswhite schrieb: When I uploaded my new package, error-message, I also went ahead and created a new category: Error Handling. Error handling is the same as debugging for you? I hope it is not intended for generating further confusion about exception handling and debugging (= help programmers to analyse errors). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
