Re: Attaching context info to an error

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

On Fri, Dec 29, 2023 at 4:54 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >> > 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.

First, I think that's a bad idea for the reasons I explained
at length.  You should "remember" errors via restarts.

Most importantly, and idea quality apart, who can be doing that
today, before h-b?  No-one or practically no-one, since it's useless
because currently the only place user code has access to
the signal also unwinds the stack, and resignalling will make a new
cons. Right?

So unless there's a specific use for it today, I recommend
specifically _not_ maintaining 'eq'ness.  This prevents
people from making the job to transition to a non-cons
representation of errors easier.

> > - 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.

Indeed this representation is really bothersome.

> > - 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?

This has to exist indeed.  Should be called "condition-resignal"
though (and the byte-compiler should warn you should use a
handler-bind instead).

> > - 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).

Let's hope so.  Skipping that then.

> > - 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.

Hard to add with that random data bag'o'things anyway.

> 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.

True!  Let's just preload EIEIO and call make-instance.  Ahaha

> 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.

Makes sense, though 100% of the cases I've seen for resignalling are
equivalent functionally to a handler-bind.

> > - 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.

I've also seen 0 examples so far where the DATA is searched inside
for actual properties.

João