Re: [Haskell-cafe] Absolutely confused with error/exception handling

My recommendation is to catch the exception in IO first, before it is lifted into the ActionCtxT. If your business logic is decoupled from the web framework (as it should be) then it should be easy enough to do this. I'm trying to write a "global" error handler which logs unhandled errors to Airbrake along with information from the request object (domain, URL, params, cookies, etc). I understand that I can make this part of my app monad, but if I don't understand why I'm unable to catch errors in MonadIO I'm bound to get stuck again, or implement it incorrectly (for example, what are the resource leaks that were being referred to?) Also what if a particular handler is not in my app monad? How do I prevent someone from accidentally adding a handler without the airbrake integration? -- Saurabh.

On Sun, Dec 18, 2016 at 3:45 AM, Saurabh Nanda
if I don't understand why I'm unable to catch errors in MonadIO I'm bound to get stuck again, or implement it incorrectly (for example, what are the resource leaks that were being referred to?)
https://mail.haskell.org/pipermail/libraries/2014-November/024224.html is the start of the rather large thread that led to the current exception primitives, which exception managers ranging from the standard `bracket` to MonadBaseControl rely on. There are quite a few examples of resource leaks during exception handling (or despite exception handling!) in it, along with many other pitfalls that can occur. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (2)
-
Brandon Allbery
-
Saurabh Nanda