Expose template names as properties

[RangerMauve]

I have a use case where I have InviteDeniedByInviterError with a reason property. I could see it being handy to be able to access the reason field without needing to parse the message text. Is it hard to add that to the types? Should I send in a PR?

[gmaclennan]

Yes, that makes sense and I can see the utility. The API design is a little tricky and there are a few options. We could just make reason a "special" param and add it as a property, but is there any justification (other than this specific need) for making reason special like that?

One option is that we auto-attach all template params as instance properties. It's nice and simple, the problem is collisions - "reserved" param names would need to be cause, message, name, stack, code, status. Probably name being reserved would be the biggest "gotcha" because I can imagine someone expecting to use messages like {name} not found. Also, renaming a param would be a breaking API change in the consuming library (changes a typed property of the error) - maybe ok? Also I think the properties would need to be typed unknown.

Another option is we namespace all the params under data or info, e.g.

const err = new SyncError({ reason: "timeout" });
err.data.reason; // "timeout"

Removes the collision issue, maybe less ergonomic saying err.data.reason vs. err.reason?

option 3: declare properties e.g.

const SyncError = createErrorClass({
  code: "SYNC_ERROR",
  message: "Sync failed",        // no template params at all
  status: 500,
  properties: ["reason", "deviceId"],
});

const err = new SyncError({ reason: "timeout", deviceId: "abc" });
err.reason; // attached, not interpolated

Properties would be unknown - adding a generic (createErrorClass<{ reason: string }>(def)) would break the current type inference.

option 4 is like what we do with cause - add a data opt { cause: err, data: { deviceId: "abc" } }. This is what modern-errors does, but there would be no typing of the properties, unless we add the generic to define the types (rather than infer them) and loose some of the "typescript 'just works' magic".

Any preferences @RangerMauve ?