-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add WARNS check. #81
base: master
Are you sure you want to change the base?
Add WARNS check. #81
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.