-
Notifications
You must be signed in to change notification settings - Fork 44
Abort on "Unknown" side conditions, don't crash #3907
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really want to merge this because it is a good idea in general (and it would fix an issue with my PR #3904 ), but I think it changes the intent of the SMTError
and mixes results and errors.
The correct model would IMHO be to return Either SMTError (Maybe Bool)
and catch the SMTSolverUnknown
case.
Left _ -> do | ||
-- TODO: we could process SMTError here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably restrict this to the SMTSolverUnknown
case. An SMTTranslationError
is an entirely different case (and the General
error was meant to cover infrastructure issues).
let errMsg = ("Inconsistent ground truth, check returns Nothing" :: Text) | ||
Log.logMessage errMsg | ||
throwE $ GeneralSMTError errMsg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really an "error", rather a defensive strategy to avoid jumping to unjustified conclusions
@@ -324,22 +322,22 @@ checkPredicates ctxt givenPs givenSubst psToCheck | |||
|
|||
case (positive, negative) of | |||
(Unsat, Unsat) -> throwSMT "Inconsistent ground truth: should have been caught above" | |||
(Sat, Sat) -> fail "Implication not determined" | |||
(Sat, Sat) -> throwE $ GeneralSMTError "Implication not determined" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, this is actually a result (neither P
nor not P
are implied)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving and following up with another PR
…d of exceptions (#3908) * Re-introduces the 'indeterminate' result for checkPredicates, and returns that on inconsistent ground truth. * In the rewrite, aborts on `SMTSolverUnknown` when checking requires clauses, but throws actual exceptions (terminating the request) on other SMT errors (translation error, general error). Follow-up to #3907
This PR makes sure we do not immediately hard-stop with an RPC error when receiving
Unknown
from Z3 in Booster.checkPredicates
Unknown
predicates as any other unclear conditions: abort rewriting