Skip to content

[Errors] Make '_OperationalEvaluationError' work in the machines #7106

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

effectfully
Copy link
Contributor

@effectfully effectfully commented May 19, 2025

This replaces

instance AsEvaluationFailure err => AsEvaluationFailure (ErrorWithCause err cause) 

with

instance AsEvaluationError err structural operational =>
        AsEvaluationError (ErrorWithCause err cause) structural operational where

making error throwing more uniform in the machines (plus it adds functionality that I need in #7029).

Also makes throwingWithCause accept a term rather than a Maybe term, as the name indicates there really should be a cause.

Also replaces

throwing_ _EvaluationFailure

with

throwingWithCause _OperationalEvaluationError CekEvaluationFailure $ Error ()

in the machines, so that the logs clearly indicate that it was error that caused an evaluation failure -- not a builtin.

@effectfully effectfully force-pushed the effectfully/errors/make-_OperationalEvaluationError-work-in-the-machines branch from e70e29a to 53305e0 Compare May 20, 2025 15:03
@effectfully effectfully requested a review from SeungheonOh May 20, 2025 19:23
@zliu41
Copy link
Member

zliu41 commented May 20, 2025

It seems the key is to replace throwing_ with throwingWithCause - adding the cause. What's the purpose of using AsEvaluationError instead of AsEvaluationFailure? What's the relationship between these two?

@effectfully
Copy link
Contributor Author

AsEvaluationError is more general, it allows one to throw both structural and operational errors. AsEvaluationFailure only allows one to throw the single operational error corresponding to an Error call. This is way too restrictive and I need other operational errors in the casing-on-booleans branch, so I figured I'd just forbid throwing Error this way, so that we uniformly throw all operational errors through AsEvaluationError.

Maybe we should replace _MachineError with _StructuralEvaluationError for consistency too, since the former is a synonym for the latter. Not sure. The former is kinda more readable and is shorter too.

@effectfully
Copy link
Contributor Author

Maybe we should replace _MachineError with _StructuralEvaluationError for consistency too, since the former is a synonym for the latter. Not sure. The former is kinda more readable and is shorter too.

Or do the opposite and alias _OperationalEvaluationError as _UserError. Would also be more readable and shorter. Or maybe we should drop Evaluation from _StructuralEvaluationError and _OperationalEvaluationError. _StructuralError is perhaps even better than _MachineError.

Copy link
Member

@zliu41 zliu41 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. The error handling could indeed use some more restructuring or refactoring. The naming - AsEvaluationError vs AsEvaluationFailure - doesn't help either.

@effectfully effectfully merged commit 8feb803 into master May 21, 2025
7 checks passed
@effectfully effectfully deleted the effectfully/errors/make-_OperationalEvaluationError-work-in-the-machines branch May 21, 2025 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants