[SPAM] Response to #55
Hello, I don't know if anyone else feels the same way about sandboxing "user-code," but I think that sprinkling catch all over any code that calls XMonadContrib code is a complete abuse of the catch mechanism. In my opinion the only exceptions that xmonad should be trying to catch are those that are truly exceptional errors as thrown by, for example, X11. Ignoring bad contrib code errors and pretending like they don't exists seems completely counter to xmonad's goal of being solid, tested code. In summary, I feel that there is a difference between not having errors and ignoring them. Xmonad is still in active development and bad code should be as visible as possible. (This has been discussed at length in the IRC channel, but I wanted to post my position to the mailing list because obviously not all of the users and developers were present.) -- Eric Mertens Phone: 503.626.6616, x155 Galois Fax: 503.214.8120 12725 SW Millikan Way Ste 290 http://www.galois.com Beaverton, OR 97005-1691 emertens@galois.com
Eric Mertens wrote:
Hello,
I don't know if anyone else feels the same way about sandboxing "user-code," but I think that sprinkling catch all over any code that calls XMonadContrib code is a complete abuse of the catch mechanism. In my opinion the only exceptions that xmonad should be trying to catch are those that are truly exceptional errors as thrown by, for example, X11. Ignoring bad contrib code errors and pretending like they don't exists seems completely counter to xmonad's goal of being solid, tested code.
In summary, I feel that there is a difference between not having errors and ignoring them. Xmonad is still in active development and bad code should be as visible as possible.
okay, change those catches to a particular interceptContribError, that creates a window saying something like "XMonadContrib has an error:" "please report it to: "or fix it" (and logs a message to stderr). That seems a bit distant from ignoring errors... and interceptContribError could be changed to be fatal to xmonad, I suppose... (perhaps this was already discussed on IRC, since I wasn't there) Isaac
On Thu, Oct 11, 2007 at 09:56:16PM -0700, Eric Mertens wrote:
I don't know if anyone else feels the same way about sandboxing "user-code," but I think that sprinkling catch all over any code that calls XMonadContrib code is a complete abuse of the catch mechanism. In my opinion the only exceptions that xmonad should be trying to catch are those that are truly exceptional errors as thrown by, for example, X11. Ignoring bad contrib code errors and pretending like they don't exists seems completely counter to xmonad's goal of being solid, tested code.
The trouble is that there's no way to catch errors in the Config file introduced by users who have never before written Haskell code without also catching errors in Contrib. I'd say that if we want to be friendly to folks that are new to Haskell, and at least make an attempt to give the impression that Haskell is a language that can be used to write robust programs. Perhaps you feel that they should be taught the perhaps more valuable lesson that pure code does not mean bug free code that doesn't crash and burn.
In summary, I feel that there is a difference between not having errors and ignoring them. Xmonad is still in active development and bad code should be as visible as possible.
I disagree. Most errors caught by catchX will still be visible bugs. Bugs that cause your X server to restart losing all your work are bugs that users aren't so likely to be eager to reproduce for us. On the plus side, removing the catchX calls will make me more productive at work, since I won't be willing to do xmonad development... or at least, if I do xmonad development I won't be willing to test the code I write. -- David Roundy Department of Physics Oregon State University
participants (3)
-
David Roundy -
Eric Mertens -
Isaac Dupree