[Haskell-cafe] IO and exceptions

[Nils Schweinsberg]

There's also the `ExceptT` monad transformer, which effectively binds
exceptions to a type:

http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html

It is not restrictive in any way, though, ie. there still can be other
excpetions raised in your application unless you account for them, but
otherwise it does a decent job at managing exceptions…

On Sun, Nov 9, 2014 at 4:01 PM, Michal Antkiewicz <mantkiew at gsd.uwaterloo.ca
> wrote:

> Whether thrown exceptions should be explicitly part of interface or not is
> still an open issue. For example, Java requires to explicitly declare the
> exception as part of method signature. And people complained... Then in
> Scala, for example, there's no such requirement. I've seen a paper showing
> negative consequences of implicit exceptions but I cannot find it now (I
> thought it was ICSE 2014...).
>
> I found some other paper contrasting implicit vs. explicit exception flows.
>
>
> http://www.les.inf.puc-rio.br/opus/docs/pubs/2009/10_NelioCacho-SBES2009.pdf
>
> So, sometimes you need to handle the exception at the call site but if
> it's required that people simply "swallow" the exception (catch and do
> nothing), sometimes you need to handle them centrally in some way. I'm not
> sure what is best for Haskell.
>
> Michal
>
>
> On Sun, Nov 9, 2014 at 8:53 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
>
>> On 09/11/14 08:38, Michael Orlitzky wrote:
>> > On 11/09/2014 08:11 AM, Roman Cheplyaka wrote:
>> >> Let's say you knew what exceptions could be thrown. What would you do
>> >> differently then?
>> >>
>> >> Typically, if it's a command-line app and something unexpected happens,
>> >> you simply present the error to the user. That's what exceptions do
>> >> already without any effort from you.
>> >>
>> >
>> > The output from the exception is usually useless, though. Rather than,
>> >
>> >   *** Exception: EACCES
>> >
>> > (or something similar, whatever, I'm making it up), I want to show:
>> >
>> >   Insufficient permissions for accessing /run/<app>. This can be fixed
>> >   by granting write and execute access on that directory to the user
>> >   under which the application is running.
>> >
>> > If the operation can fail in different ways -- like if the directory is
>> > missing entirely -- I need to pattern match on the exception and display
>> > something else.
>> >
>> > Another example: I don't want to log a "read error" in my daemon, which
>> > is what I'll get if I log the exception. I want to know *what* failed to
>> > be read. Was it a file (that a cron job deleted) or a network socket
>> > (whose connection was dropped)? I need to catch those in the code, where
>> > I know what's being read, and what the "read error" means in context.
>>
>> Both points are valid.
>>
>> Re the first, you still can achieve it by pattern-matching on
>> exceptions. The fact that you don't know the exact set of exceptions
>> makes it harder, but the truth is, for a non-trivial application, that
>> set would be huge. Like, let's say you use a database. It brings in all
>> sorts of network-related exceptions and database-level exceptions.
>>
>> The way to handle those, as you point out, is to augment them with
>> high-level information ("Could not retrieve user's data"), and then
>> maybe attach the low-level exception for debugging purposes. Again, you
>> don't really need to know the whole set of exceptions in order to do
>> that. Just wrap your database access function in 'try', and you'll know
>> that whatever exception was caught, it prevented the retrieval of user's
>> data (but keep in mind that it might be an asynchronous exception
>> unrelated to your database activity).
>>
>> Roman
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141110/71a9b4d8/attachment.html>