On Fri, Oct 12, 2007 at 01:56:17PM -0400, David Roundy wrote:
On Fri, Oct 12, 2007 at 10:32:48AM -0700, Don Stewart wrote:
case s of Left e -> mapM_ putStrLn e Right v -> Control.Exception.catch (putStrLn v) (\e -> Control.Exception.handle (const $ putStrLn "Exception") $ do e' <- Control.Exception.evaluate e putStrLn $ "Exception: " ++ take 1024 (show e'))
Right means there was no compile error. So we then show the value, forcing it. Note that it can throw an exception whose thrown value is an exception. 'evaluate' takes care of some of the work for us.
Lambdabot forks anyway, so all it really has to worry about is stopping an output flood.
That's interesting. Although Config can be assumed to be less hostile than lambdabot users, we've got a slightly harder problem in catchX, since we know of no way to force the value (as showing it does for lambdabot).
Probably worrying about calls to (error (error "Gotcha!")) is beyond the scope of catchX, as we don't need to deal with malicious code, just buggy code, and I can't imagine how someone would accidentally do something like that. Malicious people, of course, will just write bug-free code that deletes the user's home directory, which catchX can't prevent.
Of course, if IO were broken up into smaller monads, we could restrict code to not touch the filesystem if we wanted. Or even better, if we had a really tricky monad, code could be restricted to only touch the ~/.xmonadcontrib/ directory... :)
The main issue is: modify (\x -> posionWithBottoms x) That will not fail immediatly, but will cripple xmonad by causing all commands that read the state to fail, including mod-q. Your only choice is to quit xmonad wholesale. My proposal (shared, I believe, with sjanssen) is "fail early, fail often, and force the people who commit bugs to wear imaginary dunce caps". Stefan