[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Attaching context info to an error
From: |
João Távora |
Subject: |
Re: Attaching context info to an error |
Date: |
Fri, 29 Dec 2023 17:29:26 +0000 |
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
- Re: Attaching context info to an error, (continued)
- Re: Attaching context info to an error, João Távora, 2023/12/27
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/28
- Re: Attaching context info to an error, João Távora, 2023/12/28
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/28
- Re: Attaching context info to an error, João Távora, 2023/12/28
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/28
- Re: Attaching context info to an error, João Távora, 2023/12/28
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/28
- Re: Attaching context info to an error, João Távora, 2023/12/28
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/29
- Re: Attaching context info to an error,
João Távora <=
- Re: Attaching context info to an error, João Távora, 2023/12/29
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/29
- Re: Attaching context info to an error, João Távora, 2023/12/30
- Re: Attaching context info to an error, Alan Mackenzie, 2023/12/29
- Re: Attaching context info to an error, João Távora, 2023/12/29
- Re: Attaching context info to an error, Alan Mackenzie, 2023/12/29
- Re: Attaching context info to an error, João Távora, 2023/12/29
- Re: Attaching context info to an error, Alan Mackenzie, 2023/12/29
- Re: Attaching context info to an error, João Távora, 2023/12/29
- Re: Attaching context info to an error, Stefan Monnier, 2023/12/29