Hi Alaric,

On Mon 02 May 2011 12:35, Alaric Snell-Pym <alaric@snell-pym.org.uk> writes:

> On 05/02/11 11:19, Andy Wingo wrote:
>> On Mon 02 May 2011 11:51, Alaric Snell-Pym <alaric@snell-pym.org.uk> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports