Skip to content

[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

Closed
wants to merge 1 commit into from

Conversation

ejgallego
Copy link
Member

@ejgallego ejgallego commented Jun 28, 2020

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. 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:

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:

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.

See https://github.com/ejgallego/coq/tree/errors%2Bconstructor_port for an example of porting.

@ejgallego ejgallego added the kind: internal API, ML documentation... label Jun 28, 2020
@coqbot
Copy link
Contributor

coqbot commented Jun 28, 2020

For your complete information, the following job in allow failure mode has failed: test-suite:4.12+trunk+dune

@ejgallego
Copy link
Member Author

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]

@github-actions github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Feb 25, 2021
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Jul 27, 2021

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.

@coqbot-app coqbot-app bot added the stale This PR will be closed unless it is rebased. label Jul 27, 2021
@coqbot-app coqbot-app bot removed needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. stale This PR will be closed unless it is rebased. labels Aug 25, 2021
@github-actions github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Oct 12, 2021
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Nov 11, 2021

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.

@coqbot-app coqbot-app bot added the stale This PR will be closed unless it is rebased. label Nov 11, 2021
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.
@coqbot-app coqbot-app bot removed needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. stale This PR will be closed unless it is rebased. labels Nov 12, 2021
@SkySkimmer SkySkimmer added the needs: fixing The proposed code change is broken. label Jan 7, 2022
@SkySkimmer
Copy link
Contributor

With no progress for years let's close

@SkySkimmer SkySkimmer closed this Apr 17, 2024
@ejgallego ejgallego deleted the errors+constructor branch June 3, 2025 15:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: internal API, ML documentation... needs: fixing The proposed code change is broken.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants