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

Optionally preserve current stack #98

Open
fregante opened this issue Sep 25, 2024 · 4 comments
Open

Optionally preserve current stack #98

fregante opened this issue Sep 25, 2024 · 4 comments

Comments

@fregante
Copy link
Collaborator

An issue I found when throwing deserialized errors is that the thrown error has no reference to this throw point.

I think the "correct" way to throw serialized errors would be something like:

throw new Error(serialized.message, {
	cause: deserializeError(serialized),
});

Two drawbacks:

So how about:

throw deserializeError(serialized, {preserveStack: true});
@sindresorhus
Copy link
Owner

I'm ok with adding this, but I think the option is ambiguous. I'm asking myself, which stack is it preserving.

@fregante
Copy link
Collaborator Author

fregante commented Sep 26, 2024

I think it's going to be hard to encapsulate the entire behavior and raison d'être in a property name, especially since the main verb here is "deserialize error" rather than "create error"

Names:

  • asCause (doesn't explain why)
  • captureCurrentStack (doesn't say a new error is created)
  • newError (technically deserialize is already creating a new Error())
  • wrapped (good description of the result but says nothing about the behavior)

I think asCause gives the clearest picture of the result, assuming you're aware of Error#cause, even if it doesn't explain the point of doing so.

@sindresorhus
Copy link
Owner

I think asCause gives the clearest picture of the result, assuming you're aware of Error#cause, even if it doesn't explain the point of doing so.

I assumed you would just want the stack property replaced on the deserialized error with the current stack. It now sounds like you want the option to wrap it in a new error and add the deserialized one as cause?

@fregante
Copy link
Collaborator Author

Correct, check my new Error example. I want exactly that, but safer, with less code and with the ability to use the right error constructor automatically.

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

2 participants