Error constructor syntax is vulnerable to typos

[hasithaa]

I made a typo, I typed massage, instead of the message.

error("SERVICE ERROR", massage = "internal error occurred", cause = result);

One solution is to use string-literal (similar to mapping constructor) for non-field names defined in detail's record type descriptor. But it will be an incompatible change.

[jclark]

This is related to #268.

[hasithaa]

The old syntax #67 didn't have this problem, because it uses the record literal syntax.

error("ioerror", {filename: s});

[rdhananjaya]

@hasithaa Maybe I'm missing something somewhere, but I can't see how old syntax solves this issue. In my view, the root cause for the typo is message field of error detail record being optional and error detail record being open, which facilitated the new field massage. Even with the record literal syntax this issue is still possible right.

[jclark]

#268 fixed the problem for mapping constructors.

[jclark]

There will be a similar problem with functional constructors for mapping values as in #2.

[jclark]

Here's one possible approach.

• message and cause move from the detail record into the error itself
  • the type is string? and error? respectively
  • they both default to () if not specified
  • they are specified by positional arguments to the error constructor
  • lang.error provides message and cause functions to access them
• the required type of detail record is map<anydata|readonly> (with no predefined fields)
• if the error constructor uses a type that does not specify a detail record type with individual fields, then named arguments can be used to specify arbitrary fields
• if the error constructor uses a type that does specify a detail record type with individual fields, then the named arguments can only be used to specify those fields; other fields must be specified with ... and a mapping constructor (not sure if this functionality is really necessary)

If you want to specify a cause but not a message, you can specify () for the first argument (which is the same as not specifying it).

This doesn't address how to generate a message if the user doesn't explicitly specify one. There's lots of potential complexity there: i18n, formatting the message to include the fields from the detail record. Another point is that this is tied more to the distinct type than the detail record.

[jclark]

This is solved by the revised error design in #509.

[jclark]

This will be handled now in #550.