[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces

[klondike]

Luke Palmer escribió:
> On Fri, Nov 6, 2009 at 6:54 PM, klondike
> <klondikehaskellcafe at xiscosoft.es> wrote:
>   
>> 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.
>>
>> 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.
>>     
>
> You sound like you are expecting something that works exactly like the
> imperative exception handling mechanisms you are used to, and are not
> willing to accept anything else.
>   
No, I sound like I am expecting programmers comming from the imperative
world to do ugly things, maybe because I once was one.
> This "strange habit" of programmers is simply bad practice, and leads
> to just as brittle code as no exception handling, except that you get
> inexplicable error message boxes with OK buttons instead of crashes.
> You might as well just put the whole program in a catch block in IO
> and bail with something noncomittal.
>   
Now comes the time when I have to show you that not every exception
could be handled, IE a file not found exception when looking for the
config file can be fatal and force the program to stop. But what if this
is on a library? How do you suggest that the programmer knows that the
File Not Found exception is due to the lack of that config file,
specially when the code is badly (or not) documented.
> IMO, Haskell's typed exceptions (via eg. explicit-exception) *are* the
> way to go.  They keep the number of exceptional conditions that can
> occur in a body of code small -- if some code has many exceptional
> conditions, it forces you to *compose* them somehow, to come up with a
> more precise idea of what your code is doing and how it can fail.
>   
Yeah, the thing comes when you get the same kind of exceptions from
different places, you need a way to tell them appart.
> If you are just blindly passing exceptions up from the code below, the
> interface to your code is getting more and more complex.  With typed
> exceptions, the types are reflecting the complexity of the interface
> (which is precisely the purpose of types).
>   
Well, it's not like blindly pass exceptions up but more like passing
exceptions I don't know how to handle up.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20091107/c0acb1c5/signature.bin