Open sindresorhus opened 5 years ago
// @OsoianMarcel @samchon @semmel I could use some opinions on this.
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}
?
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: https://github.com/sindresorhus/serialize-error/blob/480ed369823b089ac8c75092d59c1d1f7390350e/index.js#L76
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?
@semmel , you can install util
in package.json for the browser.
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:
object
. (wanted default)I'd like
1
to be the default behavior, for consistency, but add an option to be able to opt into2
(which is the current behavior) or3
(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 thename
,message
, andstack
properties exist.