Re: Attaching context info to an error

["João Távora" <joaotavora@gmail.com>]

On Wed, Dec 27, 2023 at 5:50 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > Anyway, as Gerd suggested, I would suggest at least supporting
> > EIEIO in this handler-bind.
>
> Could you give some concrete examples of things you'd (be able to) do
> with it?

Just look at anyCL program that uses conditions, there are
very many of them.  One of them is Snooze [1] which uses them
to represent HTTP error codes.

First, we'd have to be able to `signal` such objects.  And then,
CLOS is good :-) you get access to lots of existing useful protocols.
initialize-instance, print-object, etc for free.

> Given that we start with (signal ERROR-SYMBOL ERROR-DATA) and the "other
> end point" of an error is the `condition-case` variable bound to
> a value of the form (ERROR-SYMBOL . ERROR-DATA), I find it a bit hard to
> see how we could usefully use "objects" somewhere in-between, but maybe
> some examples can help me out of the rut.

From a CL perspective, and even other languages, using our
"error symbol with some 'error property" representation of
errors is almost self-evidently inferior to just making it
a first class object.

  (define-condition my/condition (error) docstring (slots...))

Which is a much more normal way to define a hierarchy of
exceptions like you find in C++, Python, and probably many
others.

Yes, I know there is `define-error` for a while, but we'd still
be reinventing all those protocols in subtly idiosyncratic and
buggy forms ad-hoc in Elisp.  Which admittedly, is what
we've been doing all along, but why stray gratuitously when
given a (presumably cheap) chance to rejoin?

João

[1]: https://github.com/joaotavora/snooze