Re: Attaching context info to an error

[João Távora]

On Sat, Dec 30, 2023 at 4:29 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > 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 🙁).

Indeed, but that's a good thing IMO.  It tells us something we don't
_have_ to do, which is always good from a language design evolution
point of view.

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

You're right, so I can go along with `error-` just fine.  We can
make a zillion aliases later :-) (or not).

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

Resignalling a different error is fine, it's sometimes needed.
Can be just a different error message.
Resignalling the very same error, without changes, is always a
fairly bad code smell (in handler-bind-capable languages,
in C++ and current Elisp you have no other option).

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

I'm the exception. :-D  I stashed some info in the jsonrpc-error data in
hopes they would become useful for things other than printing
when handler-bind arrives.  And then there's this <grimaces>

(condition-case err
            (electric-pair--with-syntax string-or-comment
              (scan-sexps (point) (if (> direction 0)
                                      (point-max)
                                    (- (point-max))))
              (funcall at-top-level-or-equivalent-fn))
          (scan-error
           (cond ((or
                   ;; some error happened and it is not of the "ended
                   ;; prematurely" kind...
                   (not (string-match "ends prematurely" (nth 1 err)))
                   ;; ... or we were in a comment and just came out of
                   ;; it.
                   (and string-or-comment
                        (not (nth 8 (syntax-ppss)))))
                  (funcall at-top-level-or-equivalent-fn))
                 (t
                  ;; exit the sexp
                  (goto-char (nth 3 err))
                  (funcall ended-prematurely-fn)))))

Also me :-)  but I really have doubts I'm the only one.