darcs

Patch 119 switch to extensible exceptions

Title switch to extensible exceptions
Superseder Nosy List darcs-users, ganesh, twb
Related Issues
Status accepted Assigned To
Milestone

Created on 2009-12-16.01:35:28 by ganesh, last changed 2011-05-10.20:06:40 by darcswatch. Tracked on DarcsWatch.

Files
File name Status Uploaded Type Edit Remove
switch-to-extensible-exceptions.dpatch ganesh, 2009-12-16.01:35:26 text/x-darcs-patch
unnamed ganesh, 2009-12-16.01:35:26 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg9640 (view) Author: ganesh Date: 2009-12-16.01:35:27
Hi,

Don't review or apply this yet. I'm only sending it to the patch
tracker as this seems like a good place to keep work-in-progress
that others might want to look at or take further.

The basic point is to modernise darcs' exception handling away
from the old and deprecated non-extensible exceptions.

To maintain backwarsd compatibility with GHC 6.8, it uses the
extensible-exceptions package. This means that many of the imports
are of Control.Exception.Extensible. Once we drop GHC 6.8, these
imports should be changed to Control.Exception and the
extensible-exceptions dependency dropped.

I haven't tested it properly, or cleaned it up or considered alternative
techniques for converting the code. I have also conducted a fairly
literal conversion where some better cleanups of the existing code
may instead be possible.

Ganesh

Wed Dec 16 01:30:22 GMT 2009  Ganesh Sittampalam <ganesh@earth.li>
  * switch to extensible exceptions
Attachments
msg9704 (view) Author: ganesh Date: 2009-12-29.15:56:43
I've now run the tests on GHC 6.8.3, 6.10.4 and 6.12.1, and also checked the
changes more carefully and concluded that I'm happy to submit the initial
version I sent.

I think the only place where I change semantics is in a few places in
Darcs.Lock, where the code used to catch any kind of exception and now just
catches IO exceptions. Because the handlers are wrapped around an IO operation,
I think this is appropriate - in a couple of places the handler is being used to
annotate the error message with information on what file failed, and in another
place it's being used to trigger a retry. I don't think it makes sense to do
either of these things for non-IO errors.
msg9870 (view) Author: darcswatch Date: 2010-01-20.20:10:46
This patch bundle (with 1 patches) was just applied to the repository http://darcs.net/.
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__darcs.net_.html#bundle-a3c8197c8895de1ad74f6bd100a207a277343b68
msg14255 (view) Author: darcswatch Date: 2011-05-10.20:06:40
This patch bundle (with 1 patches) was just applied to the repository http://darcs.net/reviewed.
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__darcs.net_reviewed.html#bundle-a3c8197c8895de1ad74f6bd100a207a277343b68
History
Date User Action Args
2009-12-16 01:35:28ganeshcreate
2009-12-16 01:37:16darcswatchsetdarcswatchurl: http://darcswatch.nomeata.de/repo_http:__darcs.net_.html#bundle-a3c8197c8895de1ad74f6bd100a207a277343b68
2009-12-17 10:47:43ganeshsetstatus: needs-review -> followup-in-progress
2009-12-29 15:56:45ganeshsetstatus: followup-in-progress -> needs-review
messages: + msg9704
2010-01-18 09:29:16twbsetnosy: + twb
2010-01-20 20:10:48darcswatchsetstatus: needs-review -> accepted
messages: + msg9870
2011-05-10 20:06:40darcswatchsetmessages: + msg14255