Hi, I was going over the Error Handling chapter in RWH and tried out this sample - Prelude> :m Control.Exception Prelude Control.Exception> let x=5 `div` 0 Prelude Control.Exception> let y=5 `div` 1 Prelude Control.Exception> handle (\_ -> putStrLn "Text") (print x) <interactive>:1:0: Ambiguous type variable `e' in the constraint: `Exception e' arising from a use of `handle' at <interactive>:1:0-39 Probable fix: add a type signature that fixes these type variable(s) Prelude Control.Exception> Could someone please tell me what the problem is and how to resolve it? -- Regards, Kashyap
On 30 September 2010 15:23, C K Kashyap
Hi, I was going over the Error Handling chapter in RWH and tried out this sample -
Prelude> :m Control.Exception Prelude Control.Exception> let x=5 `div` 0 Prelude Control.Exception> let y=5 `div` 1 Prelude Control.Exception> handle (\_ -> putStrLn "Text") (print x)
<interactive>:1:0: Ambiguous type variable `e' in the constraint: `Exception e' arising from a use of `handle' at <interactive>:1:0-39 Probable fix: add a type signature that fixes these type variable(s) Prelude Control.Exception>
Could someone please tell me what the problem is and how to resolve it?
RWH was written before GHC 6.10 came out, and thus is using old-style exceptions. As of GHC 6.10.1 with base-4, the old-style exceptions were replaced with extensible exceptions. As such, you have two options: * Keep using old-style exceptions. With GHC 6.10 and 6.12, import Control.OldException instead of Control.Exception * Manually migrate the RWH code to new-style exceptions; there are two ways of doing this: - For production code, you should add explicit type signatures, etc. for your exception-handling functions passed to handle, etc. - For just playing around, use SomeException: e.g.: handle (\ SomeException{} -> putStrLn "Text") (print x) -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Thanks Ivan,
* Keep using old-style exceptions. With GHC 6.10 and 6.12, import Control.OldException instead of Control.Exception * Manually migrate the RWH code to new-style exceptions; there are two ways of doing this: - For production code, you should add explicit type signatures, etc. for your exception-handling functions passed to handle, etc. - For just playing around, use SomeException: e.g.: handle (\ SomeException{} -> putStrLn "Text") (print x)
Could you please review the change I've done to Don Stewart's scripting example - run s = handle (fail . show) $ do (ih,oh,eh,pid) <- runInteractiveCommand s so <- hGetContents oh se <- hGetContents eh hClose ih ex <- waitForProcess pid case ex of ExitFailure e -> fail $ "Failed with status: " ++ show e _ | not (null se) -> fail se | otherwise -> return so My change - run s = handle (\e@(SomeException{}) -> return (show e)) $ do (ih,oh,eh,pid) <- runInteractiveCommand s so <- hGetContents oh se <- hGetContents eh hClose ih ex <- waitForProcess pid case ex of ExitFailure e -> fail $ "Failed with status: " ++ show e _ | not (null se) -> fail se | otherwise -> return so -- Regards, Kashyap
On 30 September 2010 16:46, C K Kashyap
Could you please review the change I've done to Don Stewart's scripting example -
run s = handle (fail . show) $ do (ih,oh,eh,pid) <- runInteractiveCommand s so <- hGetContents oh se <- hGetContents eh hClose ih ex <- waitForProcess pid case ex of ExitFailure e -> fail $ "Failed with status: " ++ show e _ | not (null se) -> fail se | otherwise -> return so
My change -
run s = handle (\e@(SomeException{}) -> return (show e)) $ do (ih,oh,eh,pid) <- runInteractiveCommand s so <- hGetContents oh se <- hGetContents eh hClose ih ex <- waitForProcess pid case ex of ExitFailure e -> fail $ "Failed with status: " ++ show e _ | not (null se) -> fail se | otherwise -> return so
The change looks good; note, however, that you're doing something subtly different if an error occurs: in the original, if an error occured then "fail" was used to forcibly terminate the program. Your variant however returns the shown error message. Depending on the situation, this is usually a bad thing (better off to use Maybe or Either). Also, here's the official rationale about why SomeException is not recommended: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-E... . My main summation of this is that it even catches when you try to use Ctrl-c to kill a program. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
The change looks good; note, however, that you're doing something subtly different if an error occurs: in the original, if an error occured then "fail" was used to forcibly terminate the program. Your variant however returns the shown error message. Depending on the situation, this is usually a bad thing (better off to use Maybe or Either).
Also, here's the official rationale about why SomeException is not recommended: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-E... . My main summation of this is that it even catches when you try to use Ctrl-c to kill a program.
I tried this - this is consistent with the original in terms of the exiting out ... but the error message does not show up. run s = handle (\e@(SomeException{}) -> exitWith (ExitFailure 1)) $ do How can I achieve both? -- Regards, Kashyap
participants (2)
-
C K Kashyap -
Ivan Lazar Miljenovic