Re: [Scheme-reports] 6.11 Exceptions
Alex Shinn
(09 Jan 2013 02:08 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
Andy Wingo
(09 Jan 2013 08:06 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
Alex Shinn
(09 Jan 2013 09:20 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions Alaric Snell-Pym (09 Jan 2013 09:43 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
Per Bothner
(09 Jan 2013 20:02 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
John Cowan
(09 Jan 2013 20:44 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
Aaron W. Hsu
(09 Jan 2013 21:58 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
John Cowan
(10 Jan 2013 07:01 UTC)
|
Re: [Scheme-reports] 6.11 Exceptions
Alex Shinn
(09 Jan 2013 23:23 UTC)
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2013 09:19 AM, Alex Shinn wrote: > On Wed, Jan 9, 2013 at 5:05 PM, Andy Wingo <wingo@pobox.com > <mailto:wingo@pobox.com>> wrote: > > On Wed 09 Jan 2013 03:07, Alex Shinn <alexshinn@gmail.com > <mailto:alexshinn@gmail.com>> writes: > > > Secondly, its presence prohibits useful behaviors. For > example, it > > would be easy to make a `call-with-port' that closes its port on > > exceptional exits by installing a throw handler. However, since > > throw > > handlers are also used for raise-continuable, this is not > possible. > > > > Releasing resources can be done manually at the programmer > > level with their own exception handlers, even wrapping common > > patterns such as `call-with-port/close-on-exception'. > > My point is precisely that you cannot implement this behavior when > raise-continuable follows the same dispatch as raise. > > Indeed, but my point is don't throw the baby out with the > bathwater. There will be idioms where you don't want to > support continuable exceptions (perhaps your entire codebase > in fact). But please don't forbid Schemers who do want to > use them in their own code from doing so. I'm starting to use them in Ugarit. For those not in the know, it's a backup/archival system written in Chicken. When snapshotting a file fails (perhaps due to permissions or something local to that file only), a continuable exception is raised, and the front-end driving the engine gets to decide whether to log a warning and press on (better to back up as much as you can, even if some files are inaccessible), or to abort. I'm also looking into doing something similar when extraction fails due to things being missing in the vault (which might arise due to data loss, or due to deliberate excising of stuff that shouldn't have been backed up) - if just one block of a file is missing, it might be nice to write out as much of the file as you can, output a warning, and write "[[[ UGARIT MISSING BIT WAS HERE ]]]" where some content is known to be missing; but that should be configurable, and a continuable exception looks like the right way to go here. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDtO4kACgkQRgz/WHNxCGpgbQCdEH8V7mOhveBD+1x0+uKMATk4 DtkAoIh0sXTGii+FbipeeFnHY8YV6/cp =YGLH -----END PGP SIGNATURE----- _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports