Discussion

[sindresorhus]

General discussion about how this works.

Continued from sindresorhus/del-cli#34.

[tommy-mitchell]

It might also be useful to mark the name of the module throwing the error, in case a consumer only wants to present errors from a specific module:

try {
  del(path);
} catch (error) {
  if (isPresentableError(error) && error.module === 'del') {
    console.error(error.message);
    process.exit(1);
  }
  
  throw error;
}

[sindresorhus]

@tommy-mitchell Yes, maybe. But I think we need some more real-world experience with this before adding additional properties. For example, app code may want this too, not just modules. So a free-form .presentableSender property may be more flexible.

[emanuel-lundman]

In one of our projects we’ve got both a public message (presentable) and an optional more tech message. That we can throw. In that way we can present the presentable part to end users but still have more details for the errors that should both be presentable and handled by the dev team. The presentable message could in our case be multilingual when we want to as well.

It’s a bit of different approach than have an error only thrown to be presentable.
Just wanted to add it to the conversation as feedback.

TLDR; We’ve seen the use of an error that can be both presentable and include more details for the developers.

[tom-sherman]

We’ve seen the use of an error that can be both presentable and include more details for the developers.

Came here to suggest this. Instead of a Boolean property being the convention, how about a method like presentError that returns a string.

In the simple case this could just return this.message (this library could automate this plumbing) and in the more complex case you can implement it yourself.