On Tue, Mar 31, 2026 at 5:02 PM Kazu Yamamoto (山本和彦) via Haskell-Cafe
In my opinion, Show IOException should display errno. Why doesn't it display?
I'll respond here because it's broader than the github issue. Yes, I would love it if they did that, or better, included the errno in a field. Beyond that, the whole thing could use some attention I think. Every time I have to deal with IOException I relearn from scratch how hard they are to use. They have a custom Show so you can't see the data type. They don't export the constructor so you can't see what's in there. They have many ad-hoc custom functions instead which are not frequently enough used to memorize. So maybe this is entirely wrong, but what I wind up doing is matching based on the vagaries of the Show instance, and I have to reverse engineer those by looking through the source, so it winds up being me hardcoding whatever idiosyncratic thing someone used to encode ENOTDIR, instead of just checking for that constant. This pretty much defeats the point of having a structured type, but all I know is my program crashed with ENOTDIR (well, with an idiosyncratic rephrasing of that) and I need it to not do that, so I'll do whatever is easiest to make that happen. Added to that the source is pretty hard to read, as the code excerpt demonstrates a taste for ad-hoc abbreviations and many positional arguments. Of course, aside from internal source changes, it's probably not so easy to just change all these things, partially due to dummies like me relying on Show, but at least putting the E-name in there would let me do my dumb string matching on something less idiosyncratic. And not have to look in the source to try to reverse engineer what the error actually was. Even better would be to just export the ioe_errno field! There was probably a theory about keeping the type abstract to retain implementation flexibility in some way, but in practice I think the result is the opposite. There might also be some complication due to the old Haskell standard documenting an older IO error mechanism and how its API had to look, but I'm not sure how much that actually constrains the ghc IOError implementation, beyond requiring the existence of a throw and catch function you should never use.