| 02:48 | <littledan> | Looks like cause is purposely omitted right? |
| 02:49 | <littledan> | I don’t see it defined in the spec text, and Ron indicated in an earlier comment that not all errors need it |
| 03:30 | <rbuckton> | My main reason to avoid cause is that it essentially has a special meaning in errors, and in those cases is optionally defined. I wanted to avoid any potentially confusing overlap. |
| 03:35 | <littledan> | My main reason to avoid |
| 06:05 | <ljharb> | its special meaning tho is "this is what caused the error" |
| 06:05 | <ljharb> | in the case of SuppressedError, you literally described the error argument as "the cause of the suppression" |
| 06:05 | <ljharb> | iow, they already overlap, 1:1, because they both mean the same thing |
| 06:06 | <ljharb> | also, every one of the args to SuppressedError is already optional (in the sense that you can omit them and still get an error) |
| 06:08 | <ljharb> | if the error argument were removed, you'd do new SuppressedError(suppressed, message, { cause: error }), there's no chance of confusion when both error and cause are supplied, and all args remain identically optional/required. you could even make the options bag part of the .length which would imply that it's required |
| 06:11 | <ljharb> | i think this needs to be brought up in plenary explicitly, so i added a topic for it to the january agenda |