Re: Attaching context info to an error

[Alan Mackenzie <acm@muc.de>]

Hello, João.

I'll admit I've not been following this thread closely, but, ...

On Fri, Dec 29, 2023 at 03:43:54 +0000, João Távora wrote:
> On Fri, Dec 29, 2023 at 2:55 AM 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?

> > > Is it the funny cons?

> > Yup.  That's ELisp's current notion of an "error object".

> > > Can we at least get some generic functions to hide that representation
> > > so that we can change it later on?

No, no, no.  Please.  (See below.)

> > Patch very welcome, yes (and this is orthogonal to `handler-bind`).

> What operations are typically requested from it?

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

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

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

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

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

> - go through the hierarchy and add <error-name>-<data-slot>
>   accessors? Or do we already consider these details of "data" to
>   to be hidden?  If so, I think surely some violations exist,
>   hopefully not many.

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

Talk about "generic functions" and "proper objects" makes me worried
indeed.  The Emacs error handling must work fully right from early
bootstrap, i.e. when no Lisp has yet been loaded.  The "proper object"
for this is a list, of defined structure.  This is approximately what we
have at the moment.  It would be useful to tighten up this definition.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).