Re: Attaching context info to an error

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > What object exactly goes into the handler bind handlers?
>> The same (even `eq`) as the one passed to the `condition-case` handler.
> Would it matter if it weren't?

I think we want to preserve the identity of an error as it
passes through its various handlers, yes.
That makes it possible to use `eq` hash tables and to mutate them.

> - Printing?  a cl-print-object would be sufficient, I think,
>   along with a (orthogonal) directive to 'format' for using
>   cl-prin1 (why doesn't cl-princ exist?)

We cannot reliably distinguish an error object from random other cons
cells, so things like `cl-print-object` are simply not an option: the
caller needs to tell us that this is an error object.
We could have a `print-error-object`, OTOH.

> - Getting the type for resignalling purposes?  Unfortunately,
>   this returns 'cons'
>
>      (condition-case err (error "bla") (error (type-of err)))
>
>   Can it be made to return error?

If it's only for resignaling purposes, why not have
`error-resignal` instead which takes the error object itself?

> - Can we import a typep (similar to cl-typep) that understands
>   basic types EIEIO and also error hierarchy?

Nope for the reason mentioned above.
But we could have a `error-typep`.  AFAIK this kind of operation is very
rarely used in ELisp (it's only used internally in the C code which
looks for the appropriate handler).

> - simple-condition-format-control and
>   simple-condition-format-arguments?

I can't think of any ELisp code I've encountered that does something
related, so I think it's a YAGNI.

BTW, the best way to find what we need is probably to change the
`signal_or_quit` code which does the `Fcons (error_symbol, data)` and
make it build something else than a cons instead.

Then go and fix all the things that break, introducing new `error-FOO`
abstractions along the way.

> - change manual to explain that resignalling is discouraged now
>   that handler-bind exists, but if resignalling _is_ done, then
>   definitely avoid car and cdr and some form of
>
>     (signal (error-symbol err) (error-data err)
>
>   introducing these new functions?

We first want to help people make their existing code compatible with
other representations of error objects which minimal changes.
Changing the code to use `error-resignal` is trivial whereas making it
use `handler-bind` can be difficult since the semantics is subtly
different and it's not always easy to judge whether the difference
matters in this particular case.

> - go through the hierarchy and add <error-name>-<data-slot>
>   accessors?

I don't think we want to do that systematically, but yes (and I'm afraid
we'll discover along the way that the representations we use are messy
and don't always obey the subtyping suggested by the error hierarchy).

It presumably needs to come with a "similar" change on the constructor
side, so as long as we keep using (signal ERROR-TYPE ERROR-DATA) where
ERROR-DATA is a bare list it's not super pressing.

>   They shouldn't be terribly hard to find.  From some greps I
>   estimate there less than 700 condition-case that actually use
>   the variable and the majority seems to be resignalling or
>   printing.  The former will probably be fixed by
>   handler-bind anyway, and printing is a generic operation
>   already.  I checked about 20 occurances randomly, and they
>   all fell into this basket.  This also tells me that switching
>   to proper objects isn't that hard.

Even better,


        Stefan