-
Notifications
You must be signed in to change notification settings - Fork 685
[errors] Introduce error registration API #12602
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
For your complete information, the following job in allow failure mode has failed: test-suite:4.12+trunk+dune |
By the way, I remember the the reason I wanted to refine exceptions as those that carry some context, IDEs and serialization may want to handle those differently [long story, but that's the reason] |
The "needs: rebase" label was set more than 30 days ago. If the PR is not rebased in 30 days, it will be automatically closed. |
ac214f9
to
376808c
Compare
The "needs: rebase" label was set more than 30 days ago. If the PR is not rebased in 30 days, it will be automatically closed. |
Partially addresses rocq-prover#7560 Coq exception handling is complex, and requires quite a bit of meta-data on exceptions, including custom printing and documentation for each error. We introduce an error registration API that should help with the above problematic, by requiring new errors to be properly registered. There are some questions: - OCaml has support for private extensible types, however that cannot be used with exceptions unless we introduce a `CErrors.t` type. May be worth doing. - We could make the error kinds extensible too, but I'm not sure it is worth the gain, and it could be used badly. - Is the E0 variant worth it? A new error is declared as: ```ocaml module UE_Sig = struct type t = string option * Pp.t let print (hdr, pp) = Pp.strpp let doc = Pp.str "Generic User Error, to be deprecated" let kind = ErrorKind.Regular end module UserError = CoqError.Make(UE_Sig) ``` in the `.mli` file: ```ocaml module UserError = CErrors.S with type t := string option * Pp.t ``` the `with type` constraint is needed if the user wishes to expose the exception constructor.
376808c
to
39c3011
Compare
With no progress for years let's close |
Partially addresses #7560
[This PR is a WIP, in particular the implementation of the registration is still not complete, thus I'm looking for comments in the API]
Coq exception handling is complex, and requires quite a bit of
meta-data on exceptions, including custom printing and documentation
for each error.
We introduce an error registration API that should help with the above
problematic, by requiring new errors to be properly registered.
There are some questions:
OCaml has support for private extensible types, however that cannot
be used with exceptions unless we introduce a
CErrors.t
type. Maybe worth doing.
We could make the error kinds extensible too, but I'm not sure it is
worth the gain, and it could be used badly.
Is the E0 variant worth it?
A new error is declared as:
in the
.mli
file:the
with type
constraint is needed if the user wishes to expose theexception constructor.
See https://github.com/ejgallego/coq/tree/errors%2Bconstructor_port for an example of porting.