GNU bug report logs - #77725
31.0.50; Add support for types accepted by `cl-typep' to cl-generic?

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: David Ponce <da_vid <at> orange.fr>
Cc: 77725 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?
Date: Mon, 19 May 2025 18:05:03 -0400

>  ;;;###autoload
>  (defun cl-types-of (object &optional types)
>    "Return the atomic types OBJECT belongs to.
> @@ -1044,11 +1046,18 @@ cl-types-of
>               (funcall pred object)
>             (condition-case-unless-debug e
>                 (funcall pred object)
> -             (error (setq cl--derived-type-list
> -                          (delq type cl--derived-type-list))
> -                    (warn  "cl-types-of %S: %s"
> -                           type (error-message-string e))
> -                    nil)))
> +             ;; Catching `cl-type-error' means it comes from recursive
> +             ;; calls to `cl-types-of', so propagate the error until
> +             ;; escaping the outermost call to `cl-types-of'.
> +             (cl-type-error
> +              (signal (car e) (cdr e)))
> +             (error
> +              ;; If checking TYPE signals an error, disable TYPE and
> +              ;; signal a `cl-type-error' error mentioning TYPE and
> +              ;; the underlying error.
> +              (setq cl--derived-type-list
> +                    (delq type cl--derived-type-list))
> +              (signal 'cl-type-error (list type e)))))
>           (push type found))))
>      (push (cl-type-of object) found)
>      ;; Return the list of types OBJECT belongs to, which is also the list

Hmm... usually we have two preoccupations:

- Notify the existence of a problem.
- Try and provide "graceful degradation", i.e. still do something
  useful, despite the problem.
- Make it easy to debug.

Both the "before" and "after" versions of the code above seem to satisfy
those needs in more or less the same way, but your new code is more
complex, so I'm wondering what do you see as the advantage?

BTW, a related option is to do something like:

    (let ((error t))
      (unwind-protect
          (prog1 (funcall pred object)
                 (setq error nil))
        (when error
          (setq cl--derived-type-list
                (delq type cl--derived-type-list)))))


- Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.