On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink <hessel...@gmail.com> wrote:
> On Wed, Jul 10, 2013 at 10:39 AM, John Lato <jwl...@gmail.com> wrote: > > I think 'shouldBeCaught' is more often than not the wrong thing. A > > whitelist of exceptions you're prepared to handle makes much more sense > than > > excluding certain operations. Some common whitelists, e.g. filesystem > > exceptions or network exceptions, might be useful to have. > > You'd think that, but there are common use cases. For example, if you > have a queue of work items, and a thread (or threads) processing them, > it is useful to catch all exceptions of these threads. You can then > log the exception, remove the item from the queue and put it in some > error bucket, and continue on to the next item. The same goes for e.g. > socket listening threads etc. > > The thing here is that you are *not* actually handling the specific > exception, but instead failing gracefully. But you still want to be > able to kill the worker threads, and you don't want to handle > exceptions that you cannot recover from even by moving on to the next > work item. > I think that's a particularly niche use case. We have some similar code, and our approach is to have the thread re-throw (or terminate) after logging the exception. There's a separate thread that monitors the thread pool, and when threads die new ones are spawned to take their place (unless the thread pool is shutting down, of course). Spawning a new thread only happens on an exception and it's cheap anyway, so there's no performance issue. As Haskell currently stands trying to sort out thread-control and fatal-for-real exceptions from other exceptions seems rather fiddly, unreliable, and prone to change between versions, so I think it's best avoided. If there were a standard library function to do it I might use it, but I wouldn't want to maintain it.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
