You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 3, 2026. It is now read-only.
Presently the design of Assay is to define the assertion logic as class method in the Assay classes. This has the benefit of not requiring the creation of an object to test an assertion, and the Assay class is only initialized if the assertion fails.
OTOH, this means there is no state, so there methods can't effectively share data. Generally this is not an issue, but for raise, rescue and throw assertions it's a little bit of an issue b/c we can't pass the actual result to the message method in order to inform the developer what actually occurred.
For raise and rescue we might get around this by using $!, but I do not think there is any such work around for throw. Nor if ti becomes an issue for other assays. There are two possible solutions:
Use our won global to pass along failed assertion information.
Define assay logic at the instance level. In some ways I am partial to this solution, though it has some drawbacks of it's own. Mainly, that if Assay are to remain subclasses of Exception we must navigate interface issues between assertion logic and error logic (possible but a bit tricky with initializer), Also, it means every assertion creates a new object --a bit hard on memory foot print for a very temporary object.
Presently the design of Assay is to define the assertion logic as class method in the Assay classes. This has the benefit of not requiring the creation of an object to test an assertion, and the Assay class is only initialized if the assertion fails.
OTOH, this means there is no state, so there methods can't effectively share data. Generally this is not an issue, but for raise, rescue and throw assertions it's a little bit of an issue b/c we can't pass the actual result to the message method in order to inform the developer what actually occurred.
For raise and rescue we might get around this by using $!, but I do not think there is any such work around for throw. Nor if ti becomes an issue for other assays. There are two possible solutions: