8000 Preserve the generated error class on serialize by jez · Pull Request #3146 · sorbet/sorbet · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Preserve the generated error class on serialize #3146

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

Merged
merged 3 commits into from
Jun 4, 2020
Merged

Preserve the generated error class on serialize #3146

merged 3 commits into from
Jun 4, 2020

Conversation

jez
Copy link
Collaborator
@jez jez commented Jun 4, 2020

Motivation

We do some fancy wrapping logic that tries to provide more context on
where the error message came from when it came from the generated
serialize, probably because the line numbers look terrible with the
module_eval tricks we're doing.

The problem is that this means sometimes the error kind can change
depending on the order the code loads.

The change to the test exemplifies this. We swallowed a NoMethodError
and converted it to a TypeError.

Test plan

See included automated tests.

We do some fancy wrapping logic that tries to provide more context on
where the error message came from when it came from the generated
serialize, probably because the line numbers look terrible with the
module_eval tricks we're doing.

The problem is that this means sometimes the error kind can change
depending on the order the code loads.

The change to the test exemplifies this. We swallowed a NoMethodError
and converted it to a TypeError.
@jez jez requested a review from a team as a code owner June 4, 2020 01:13
@jez jez requested review from elliottt and removed request for a team June 4, 2020 01:13
@jez
Copy link
Collaborator Author
jez commented Jun 4, 2020

cc @timr-stripe @djudd-stripe

@jez
Copy link
Collaborator Author
jez commented Jun 4, 2020

This changes some behavior on Stripe's codebase:

https://go/builds/bui_HOwAibuRsofU7Q

but i consider all the changes good changes. I'll address them before landing this.

@djudd-stripe
Copy link
Contributor

Do we want to be paranoid about the possibility of exception classes that don't have a single-argument constructor accepting a string?

@jez
Copy link
Collaborator Author
jez commented Jun 4, 2020

Do we want to be paranoid about the possibility of exception classes that don't have a single-argument constructor accepting a string?

@djudd-stripe I thought about that. Do you have a suggestion for how we could do it?

@djudd-stripe
Copy link
Contributor

@jez I think the most robust way would be to do something like raise (err.class.new(msg) rescue TypeError.new(msg))

Hideous but maybe the right thing to do?

@jez jez merged commit 08c1489 into master Jun 4, 2020
@jez jez deleted the jez-fix-raise branch June 4, 2020 22:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0