Lazy streams and unsafeInterleaveIO

[Glynn Clements]

Jyrinx wrote:

> > [...] and
> > the inability to handle exceptions (the actual exception won't occur
> > until after e.g. getContents has returned).
> 
> But how does this differ from strict I/O? I mean, say there's a disk 
> error in the middle of some big file I want to crunch. Under traditional 
> I/O, I open the file and proceed to read each piece of data, process it, 
> and continue to the next one, reading the raw data only as I need it. 
> When I hit the error, an exception will be thrown in the middle of the 
> operation. In lazy I/O, I might use getContents to get all the 
> characters lazily; the getContents call will read each piece of data as 
> it's needed in the operation - in other words, the data is read as the 
> program uses it, just like with traditional I/O. And when the error 
> occurs, the operation will be unceremoniously interrupted, again the 
> same as by strict I/O. In mean, if an exception is thrown because of a 
> file error, I can't hope to catch it in the data-crunching part of the 
> program anyway ...

No, but with strict I/O, you are bound to be "within" the IO monad
when the exception is thrown, so you *can* catch it.

If you are just going to allow all exceptions to be fatal, and don't
need any control over I/O ordering, you may as well just use lazy I/O. 
However, if you are writing real software as opposed to just toy
programs, you have to handle exceptions; e.g. a web browser which died
every time that a server refused a connection wouldn't be of much use.

-- 
Glynn Clements <glynn.clements@virgin.net>