Conversation
There is an open pull request to add the `warns` check to fiveam. If that pull request is merged, the `warns` check here should no longer be used. The check added by this commit will ensure that the `warns` defined in warns-check.lisp is only used if `warns` is not already defined. See lispci/fiveam#81
The SIGNALS check can correctly detect whether a block of code signals a warning, but it also aborts the code block's execution. That's appropriate for checking for an error, but not for a warning. This new check confirms that a warning of a particular class is raised, a la SIGNALS, but also allows the block of code in its scope to complete, which may be more natural for some cases.
|
Good idea, but it makes more sense to modify SIGNALS and instead have it abort only when the condition is a subtype of CL:ERROR. |
|
If you would like such a mod, I could do it. I didn't do it before because changing Let me know what you would prefer, and I will do one of the other. |
|
Yes, I prefer to modify |
SIGNALS now captures the return value of the signaling block, EXCEPT when the condition signaled is an error, in which case there may not be a value to return. Changes in tests.lisp illustrate the trade-offs.
|
I have a new version of this, but it turned into a kludge, because it required some DWIMing. The reason that the previously-existing So my DWIMed-up version of
In all cases except error, Honestly, I think what would have been best would be either to pull the I have pushed the latest, kludgy version to this PR so you can look it over and make a choice. |
The SIGNALS check can correctly detect whether a block of code signals
a warning, but it also aborts the code block's execution. That's
appropriate for checking for an error, but not for a warning. This new
check confirms that a warning of a particular class is raised, a la
SIGNALS, but also allows the block of code in its scope to complete,
which may be more natural for some cases.