IOError vs. Exception vs. IOException

Alastair Reid
31 Oct 2002 21:13:14 +0000

Ross Paterson <> cryptically writes:
> Shouldn't IOError be identified with IOException rather than Exception? 

I had to grovel through the code to understand what this question
means.  It seems that GHC.IOBase contains these definitions:

  type IOError = Exception
  data Exception
    = ArithException      ArithException
    | ...
    | IOException         IOException
    | ...

  data IOException
   = IOError {
       ioe_handle   :: Maybe Handle,   -- the handle used by the action flagging
                                       -- the error.
       ioe_type     :: IOErrorType,    -- what it was.
       ioe_location :: String,         -- location.
       ioe_descr    :: String,         -- error type specific information.
       ioe_filename :: Maybe FilePath  -- filename the error is related to.
I think the idea is that we want code protected using catch clauses to
be safe against not just IOErrors but also all the exceptions
(division by zero, etc) that can happen.  Since the type of 'catch' is
fixed by the report, we have to make IOError include all those types.

The report deliberately specifies IOError in such a way that
additional kinds of IOError can be easily added.

This only leaves the question of whether division by 0 is an IO error
or is a pure error.  The argument is that the only thing which causes
evaluation to happen is IO - if your program doesn't interact with the
outside world, it might as well not do anything.  So, in that sense,
all errors are errors triggered by performing IO.  [You can disagree
with this argument if you like - the fact will remain that we'd like
Prelude.catch to catch as many exceptions as possible even if the
names of the types seem a little screwy when we do that.]

(Well, there's also the other question of how much work it'll take to
make Hugs fit this framework.  I wrote a lot of that code but I don't
honestly remember what it looks like.)