Henning Thielemann escribió:
That's what I meant with my post: Programming errors (like "head []") are not handled by control-monad-exception. As far as I understand, control-monad-exception makes _exceptions_ explicit in the type signatures, not programming errors. Why and how would you make possible programming errors explicit in the type? But for exceptions (e.g. "file could not be found") a detailed stack trace is not of much use. I think you have overlooked a few things. First, not every developer knows each one of the lines in the code well enough as to see where a exception comes from, specially when you are not the author of that code.
It seems again to me, that mixing of (programming) errors and exceptions is going on, and I assumed that the purpose of control-monad-exception is to separate them in a better way. You know, could you tell me when using head on an empty list is a
Of course, that wouldn't mind so much unless you see another thing, if we don't know which exceptions can be launched by a operation then you will get it on the upper frame and rendered unable to solve it. Use typed exceptions (as this library intends to) you may say. Ok, now we have another problem, the strange habit of coders to keep the exceptions they don't know/can't treat going up and up and up, until then usually hit the top frame and you are screwed. You can check some Java code (to see an example on how this happens) as some of these exceptional conditions are put on the method's signature. About detecting programming errors making them explicit on the type you can use IOized versions of the dangerous functions and use a special Exception type for them which would, usually, be caught at the top frame then showed. programming error and when it is a exception, I have seen both cases...