one icon indicating copy to clipboard operation
one copied to clipboard

Generalize nomenclature for error handling

Open propensive opened this issue 2 months ago • 1 comments

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

propensive avatar Nov 05 '25 09:11 propensive

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]

propensive avatar Nov 05 '25 09:11 propensive