Why can Haskell exceptions only be caught inside the IO monad?

Question

Can anybody explain why exceptions may be thrown outside the IO monad, but may only be caught inside it?

Answer 1

One of the reasons is the denotational semantics of Haskell.

One of the neat properties of (pure) Haskell functions is their monotonicity -- more defined argument yields more defined value. This property is very important e.g. to reason about recursive functions (read the article to understand why).

Denotation of exception by definition is the bottom, _|_, the least element in poset corresponding to the given type. Thus, to satisfy monotonicity requirement, the following inequality needs to hold for any denotation f of Haskell function:

f(_|_) <= f(X)

Now, if we could catch exceptions, we could break this inequality by "recognizing" the bottom (catching the exception) and returning more defined value:

f x = case catch (seq x True) (\exception -> False) of
        True -> -- there was no exception
            undefined
        False -> -- there was an exception, return defined value
            42

Here's complete working demonstration (requires base-4 Control.Exception):

import Prelude hiding (catch)
import System.IO.Unsafe (unsafePerformIO)
import qualified Control.Exception as E

catch :: a -> (E.SomeException -> a) -> a
catch x h = unsafePerformIO $ E.catch (return $! x) (return . h)

f x = case catch (seq x True) (\exception -> False) of
        True -> -- there was no exception
            undefined
        False -> -- there was an exception, return defined value
            42

Another reason, as TomMD noted, is breaking referential transparency. You could replace equal things with equal and get another answer. (Equal in denotational sense, i.e. they denote the same value, not in == sense.)

How would we do this? Consider the following expression:

let x = x in x

This is a non-terminating recursion, so it never returns us any information and thus is denoted also by _|_. If we were able to catch exceptions, we could write function f such as

f undefined = 0
f (let x = x in x) = _|_

(The latter is always true for strict functions, because Haskell provides no means to detect non-terminating computation -- and cannot in principle, because of the Halting problem.)

Answer 2

Because exceptions can break referential transparency.

You're probably talking about exceptions that are actually direct results of the input. For example:

head [] = error "oh no!" -- this type of exception
head (x:xs) = x

If you are lamenting not being able to catch errors like this then I assert to you that the functions shouldn't be relying on error or any other exceptions but should instead use a proper return type (Maybe, Either, or perhaps MonadError). This forces you to deal with the exceptional condition in a more explicit manner.

Unlike the above (and what causes the issue behind your question), exceptions can be from signals such as out of memory conditions that are completely independent of the value being computed. This is clearly not a pure concept and must live in IO.

Answer 3

I might be wrong in my explanation, but that's how I understand it.

Since functions are pure in Haskell, the compiler has the right to evaluate them in any order he wishes and it still produces the same result. For example, given function:

square :: Int -> Int
square x = x * x

expression square (square 2) can be evaluated in different ways, but it always reduces to the same result which is 16.

If we call square from somewhere else:

test x = if x == 2 
         then square x 
         else 0

square x can be evaluated later, "outside" the test function when the value is actually needed. At that moment the call stack can be completely different from the one you would expect say in Java.

So even if we wanted to catch a potential exception thrown by square, where should you place the catch part?