one
one copied to clipboard
Generalize nomenclature for error handling
I've never been fully happy with recover/mitigate followed by within. I propose that a unified introduction should be used, whereas, and different secondary terms, such as protect, mitigate and validate.
The choice of whereas is consist with legal or constitutional terminology. It introduces context before the main point, which is exactly what is done here. (And is necessary because the type system does not allow it to be written the other way round.)
We would need to change the whereas to produce a value with appropriate types. These would need to include:
- a tuple of error types handled
- the focus type
- a tuple of error types possibly raised by the block
- the LUB of the RHS of the cases
If we presume that focused will add at <position> to the end of a message, we could write,
whereas[JsonPointer]:
case ParseError() => m"could not parse the file".focused
case NumberError(n) => m"the number $n was not valid".focused
. validate(MultiError(_)):
json.as[Entity]