You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Error handling is currently handled fairly robustly from a pattern perspective, with the crate-specific Error enum used to differentiate multiple variants of internal error, and all Chipolata back-end functions bubbling-up any such errors to the hosting application. However at present the enum variants contain no data fields that hold details of the actual errors; all that's reported is the type of error e.g. "invalid operands" (but without saying what the operands are. This should be expanded:
Data pertinent to the specific error should be added to the enum
Surrounding context (e.g. CPU cycles) should also be added
The text was updated successfully, but these errors were encountered:
Renaming the previous Error enum to ErrorDetail, and adding fields to many of the variants to allow details of the specific error to be captured
Adding a new ChipolataError struct, that holds a StateSnapshot representation of the processor at the point of error, plus an associated ErrorDetail instance
Public methods of Processor now return ChipolataError, while lower-level functions bubble-up ErrorDetail instead (captured within the ChipolataError before Processor passes this back to the hosting application
Error handling is currently handled fairly robustly from a pattern perspective, with the crate-specific
Error
enum used to differentiate multiple variants of internal error, and all Chipolata back-end functions bubbling-up any such errors to the hosting application. However at present the enum variants contain no data fields that hold details of the actual errors; all that's reported is the type of error e.g. "invalid operands" (but without saying what the operands are. This should be expanded:The text was updated successfully, but these errors were encountered: