Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: create ERC20OverwriteFactory utils #12
feat: create ERC20OverwriteFactory utils #12
Changes from 1 commit
86457cf
b033fae
e58c5bb
5af81da
7379518
e2cc259
e9f7bdf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here with the unwraps. We also need to decide if we want the program to just panic and terminate if this fails (which will happen with
unwrap
andexpect
etc.) or do we want the user to decide how to handle the error. If we want the user to be able to handle the error we need to return aResult
and propagate these internal errors instead of panicking.I personally think we should return a Result... the user might want to skip that simulation that this is making fail, but keep their program running and simulating non-vm pools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I agree with you - I'm thinking about the scenarios where this fails:
And I am not sure it's beneficial to return a result here - these are not really expected errors that one can just skip for one simulation and expect that the next simulation will be okay. If any one of those things is wrong - it's truly game over for all sims. I do think in this case it's more beneficial to use
expect
.Let me know if I'm missing something!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... yeah, I agree with you in terms of vm only simulations. But in rust I tend to lean towards giving the call site/user the power to choose.
E.g. If I'm a small solver that mainly uses native protocols I might decide to just handle this error by ignoring vm protocols and just logging a warning. To me my focus is on keeping my native simulations going.
On the other side, if I rely on vm simulations I can then choose to panic on this error.
I like having the choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes more sense! I'll add that in then :)