check-exn uses the wrong/misleading message when no exn is raised

[Matthias Felleisen]

(check-exn #px"bad" (λ () 1) "no state")

yields

--------------------
. FAILURE
name:       check-exn
location:   interactions from an unsaved editor:33:2
params:     '(#px"bad" #<procedure>)
message:    "no state"

Could this say: "no exception raised: no state"? That would be information.

[Jack Firth]

For comparison, when the message argument is omitted:

(check-exn #px"bad" (λ () 1))

...the failure says:

--------------------
. FAILURE
name:       check-exn
location:   unsaved-editor:5:0
params:     '(#px"bad" #<procedure>)
message:    "No exception raised"
--------------------

There's a similar but less severe problem when the exception doesn't satisfy the regexp / predicate. This test code:

(define (raise-good)
  (raise (make-exn:fail "good" (current-continuation-marks))))

(check-exn #px"bad" raise-good)
(check-exn #px"bad" raise-good "kaboom!")

...outputs these two failure messages:

--------------------
. FAILURE
name:         check-exn
location:     unsaved-editor:8:0
params:       '(#px"bad" #<procedure:raise-good>)
message:      "Wrong exception raised"
exn-message:  "good"
exn:          #(struct:exn:fail "good" #<continuation-mark-set>)
--------------------
--------------------
. FAILURE
name:         check-exn
location:     unsaved-editor:9:0
params:       '(#px"bad" #<procedure:raise-good>)
message:      "kaboom!"
exn-message:  "good"
exn:          #(struct:exn:fail "good" #<continuation-mark-set>)
--------------------

Could this say: "no exception raised: no state"?

Yes, I think that's a good solution. I'm not sure what the right fix for the wrong-exception-raised case is however.

I personally never use the message argument to checks. Instead I use test case names to do that sort of thing. I wonder how common that is, or if that's in general a better approach than these check message arguments.