Hi Alaric, On Mon 02 May 2011 12:35, Alaric Snell-Pym <[email protected]> writes:
> On 05/02/11 11:19, Andy Wingo wrote: >> On Mon 02 May 2011 11:51, Alaric Snell-Pym <[email protected]> writes: >> >>> (EXCEPTION? foo) >>> (EXCEPTION->STRING foo) >>> ...and for advanced implementations, (EXCEPTION-BACKTRACE foo) etc... >> >> This assumes a mode of debugging after the stack is unwound, instead of >> debugging before throwing the exception. In the latter case, not only >> do you have the possibility to restart, you don't need to reify anything >> to have access to a backtrace. >> >> I don't think this is the sort of thing that a Scheme report should >> standardize. > > Same here. I wasn't suggesting standardising it, merely that for > implementations that have this concept, a way of providing it across > ERROR exceptions and more complex hierarchical exceptions would be nice. Still, it seems that you are promoting a data type for exceptions, and my point is that sometimes that data is an implicit function of the state of the system, instead of being all reified and packed into one object. So if there is no data type, there can be no "exception" in the hierarchy. In such a system an error is what's left after an exception has been thrown; the exception, properly speaking, never existed. Andy -- http://wingolog.org/ _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
