Re: Attaching context info to an error

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

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

Indeed, until now the identity of an error object can't be "noticed".
The only place other than the `condition-case` where an error can appear
is in `signal-hook-function` and this doesn't receive the error object
(it receives it in two pieces instead 🙁).

> So unless there's a specific use for it today,

Just because we can't think of a use case today doesn't mean there can't
be a good use case.  And yes, I do have some use cases.  Those use cases
may be able to use other approaches as well, but the various options all
have pros and cons.

> I recommend specifically _not_ maintaining 'eq'ness.
> This prevents people from making the job to transition to a non-cons
> representation of errors easier.

You lost me here.

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

Actually, it's not.  We've lived with it quite happily for about 40
years now.  In practice, we really don't do much with error objects
other than re-signal them or pass them to `error-message-string`.

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

Emacs's naming convention in this area is a bit murky, but I think it's
leaning towards `error` (e.g. the `error-message-string` function, the
`define-error` macro, the `error-conditions` and `error-message`
properties).
This said, as long as the new functions are nicely placed together in
their own namespace prefix, I'll be happy, so if you prefer
`condition-`, I can go along with that.

> (and the byte-compiler should warn you should use a
> handler-bind instead).

As I mentioned elsewhere, running code inside a `handler-bind` means
running in some arbitrary dynamic context, which can have surprising
effects because in ELisp dynvars influence the execution of a *lot* of
primitives (even `eq` is not immune).  So I don't think I can honestly
claim that re-signaling an error is almost always wrong.  Maybe with
more practice, I'll reach this conclusion, but I'm definitely not
there yet.  So, warning about resignaling seems premature.

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

That's my impression as well.
The fact that the "data" part has no clearly defined shape (other than
being a list) means that it's used a bit "without purpose": I think that
in most cases, programmers put data in there only under the expectation
that it'll be useful when displayed in an error message or a backtrace.


        Stefan