[Rusky]

IO is not (primarily) about where failures lie, but about where side effects lie- side effects are where you start caring about the order of execution.

Array indexing failures, on the other hand, are not something you typically care about at quite that granularity- they're usually just bugs, not something to recover from except perhaps at a much higher level.

The parent comment lumps these kinds of failures in with non-termination, which in pure functions is also typically just a bug rather than a recoverable failure. And this one isn't something you can generally check for, either- with lazy evaluation, every type in a Haskell program by default includes a "bottom" value.

I think both choices were made for a similar reason- actually handling array bounds check failures everywhere is pointless tedium (and often better folded into the iteration itself), and actually handling possible non-termination by using a total language can also get pretty tedious. There are languages that do both, and they have their uses, but Haskell went a different direction.

[dundarious]

You make a good point about IO, I forgot how it's also not great about errors (but isn't there are an IO monad with better error treatment? -- it has been several years...). I also agree about granularity and tedium, but that's orthogonal to whether exceptions are the best way to approach such errors, and I don't think they are. Even Go's approach of explicit if-return is not tedium to me, but there are even less tedious approaches, that still let you handle the handle-able errors and do some last-ditch cleanup or just panic on the unhandle-able ones like indexing errors.

The interesting thing about Haskell exceptions are the async ones and the ability to `throwTo`, but I never really had a use for that, so on the whole, that was a bit of an encumbrance too. It's like trying to write exception safe C++ -- tedious and easy to get wrong. I remember a fair few sections of Parallel and Concurrent Programming in Haskell that temporarily didn't handle exceptions correctly, and it often wasn't for pure pedagogical reasons. Great book though.