More flexible error formatting #354

New Issue

2021-11-11T19:41:44+09:00

zxq9 commented

2021-11-11 19:41:44 +09:00

(Migrated from gitlab.com)

Created by: hanssv

When errors (and warnings?) are put together they are prepared for presentation as a string. This is not always great, for example:

https://github.com/aeternity/aesophia_http/issues/80
and https://github.com/aeternity/aesophia_http/issues/79

We should move the formatting further down the line (pp function in aeso_errors?) - and perhaps provide more ways to present the raw error-structures.

*Created by: hanssv* When errors (and warnings?) are put together they are prepared for presentation as a string. This is not always great, for example: https://github.com/aeternity/aesophia_http/issues/80 and https://github.com/aeternity/aesophia_http/issues/79 We should move the formatting further down the line (`pp` function in `aeso_errors`?) - and perhaps provide more ways to present the raw error-structures.

ghallak commented

2021-12-16 20:34:29 +09:00

(Migrated from gitlab.com)

@hanssv Moving the formatting down the line (in this case moving mk_error from aeso_ast_infer_types to aeso_errors) would allow throwing errors in their original form (e.g. {unbound_variables, {id, _, "x"}} instead of #err record) and it would then be possible for aesophia_http to write its own version of mk_error to make errors formatting suitable for the output of aesophia_http.

Another way would be to write 2 versions of the errors messages that is produced by mk_error, the current one, and one that is suitable for the output of aesophia_http (without new lines and without line and col numbers) and have a command line option to choose which type of formatting do we want.

The first method would require making changes to aesophia_http when new types errors are added, and the second might bloat the code, especially if more types of formatting are added in the future.

@hanssv Moving the formatting down the line (in this case moving `mk_error` from `aeso_ast_infer_types` to `aeso_errors`) would allow throwing errors in their original form (e.g. `{unbound_variables, {id, _, "x"}}` instead of `#err` record) and it would then be possible for `aesophia_http` to write its own version of `mk_error` to make errors formatting suitable for the output of `aesophia_http`. Another way would be to write 2 versions of the errors messages that is produced by `mk_error`, the current one, and one that is suitable for the output of `aesophia_http` (without new lines and without line and col numbers) and have a command line option to choose which type of formatting do we want. The first method would require making changes to `aesophia_http` when new types errors are added, and the second might bloat the code, especially if more types of formatting are added in the future.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/sophia#354