Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to decide behavior #25

Open
sindresorhus opened this issue Sep 23, 2019 · 5 comments
Open

Add option to decide behavior #25

sindresorhus opened this issue Sep 23, 2019 · 5 comments

Comments

@sindresorhus
Copy link
Owner

sindresorhus commented Sep 23, 2019

You can throw anything in JS, but it's a bad practice. I'd like to have it fail rather than silently accept anything. Though, it's not a good default, so should be opt-in.

Actually, there's 3 possible behaviors:

  1. Always return an object. (wanted default)
  2. Passthrough non-object values. (current default)
  3. Throw on non-object input.

I'd like 1 to be the default behavior, for consistency, but add an option to be able to opt into 2 (which is the current behavior) or 3 (which would be the strict behavior). This should be a single option.

Another benefit of 1 is that the TypeScript types can be better. We can guarantee it's an object and we can also guarantee that the name, message, and stack properties exist.

@sindresorhus sindresorhus changed the title Add a strict option that throws on anything that is not an Error object Add option to decide behavior Sep 23, 2019
@sindresorhus
Copy link
Owner Author

// @OsoianMarcel @samchon @semmel I could use some opinions on this.

@semmel
Copy link

semmel commented Sep 23, 2019

Yes, in practice all sorts of crap is thrown. Other than non-objects, e.g. objects which contain a collection of several errors and root level name, message nor stack.

My expectation from serialize-error would be that it produces something "serializable" from my input. If that is possible it should not fail. Thus I don't like option 3.

Another benefit of 1 is that ... we can also guarantee that the name, message, and stack properties exist.

Yes, but the values of name and stack would not be very useful, would they?

I can imagine some mapping from non-object primitives to .message simply like serializableError.message = String(nonObject) That would work for non-objects like Strings (non-empty), Numbers, Symbols, Dates ...

But what would the message property be for {foo: "bar", doc: window.document}?

@sindresorhus
Copy link
Owner Author

Yes, but the values of name and stack would not be very useful, would they?

They would be useful in the sense that they would indicate that an invalid error was passed.

But what would the message property be for {foo: "bar", doc: window.document}?

It would use util.inspect, same as:

return new NonError(value);

@semmel
Copy link

semmel commented Sep 23, 2019

Requiring the Node.js built-in util package for util.inspect means that serialize-error no longer works in a browser?

Otherwise I would be polite to add a build step to generate some distribution files for the browser using a util shim?

@jcald1
Copy link

jcald1 commented Mar 17, 2020

@semmel , you can install util in package.json for the browser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants