Hi, how do we test that a failure is a proper error and not an anomaly these days? (It seems that the behavior of Fail
changed in 8.11 wrt to anomalies.)
(It seems that the behavior of Fail changed in 8.11 wrt to anomalies.)
WDYM?
Below, Extraction F
raises a Not_found
anomaly. From 8.11, this anomaly is catched by Fail
.
Require Import Extraction.
Module Type T. End T.
Module F (X:T). Declare Module X : T. End F.
Fail Extraction F.
Possibly related to the discussion in https://github.com/coq/coq/issues/12737?
I guess the noncritical from be9a1834a48393185ec9cfd9c18d157fd2a7ff02 should be not (is_anomaly)?
is_anomaly is not great code though (calling is_handled so it does printing and throws it away)
Gaëtan Gilbert said:
I guess the noncritical from be9a1834a48393185ec9cfd9c18d157fd2a7ff02 should be not (is_anomaly)?
is_anomaly is not great code though (calling is_handled so it does printing and throws it away)
I would say so. Is there some consensus, or at least not-not-consensus, that we don't want Fail
to catch anomalies?
Janno said:
Possibly related to the discussion in https://github.com/coq/coq/issues/12737?
Related in the sense that it is difficult to define what is an anomaly w/o calling the error handler which will then be in time proportional to the number of declared errors. But unrelated in that it is about a handler in a different part of the code.
Then catchable_exception
catches Not_found
, Exit
, NotConvertible
, and any other exceptions that is supposed to only communicate internal information between internal functions. Should this be considered a bug?
Fail
not catching anomalies sounds quite sensible indeed.
that’s also what #12737 argues for…
and this choice seems canonical, as long as we agree that the right reaction for anomalies lies in bugtracking not backtracking.
Last updated: Oct 13 2024 at 01:02 UTC