feat(params): adding error case in UnmarshalInto func#70
feat(params): adding error case in UnmarshalInto func#70Caroline-theotter wants to merge 6 commits intomasterfrom
Conversation
733dcc7 to
9d104f6
Compare
|
@Caroline-theotter I went through the PR, and I see a few red flags ( Could you show me a simple example from your test case to fully understand the behavioural difference before and after your feature? |
| @@ -92,6 +98,22 @@ func (p Params) UnmarshalInto(receivers ...interface{}) error { | |||
| return errors.New("not enough params to decode") | |||
There was a problem hiding this comment.
Is this check required anymore? if you pass more receivers than params, isn't it enough to set them to nil? That seems to be the intended behavior copied across from go-ethereum library at line 169
85345e6 to
7dcebde
Compare
|
The only difference in the expected behaviour lies in the prefix I find this change quite heavy for an outcome that is unclear. This code is used in several projects and sometimes in hot paths, so I think an explicit motivation for this change and perhaps a benchmark to show how it performs would be great. If you intend to mimic the behaviour of a specific implementation (e.g. Geth), then I would question if this is the right place for it. |
|
@basgys I understand you POV. And tell me if I'm wrong but that change can be a problem if a hardcoded error is in a condition, right ? I checked in the infura repo where I can find, for example, the hardcoded error |
Current situation
Expected situation
Adding the indexation of the invalid argument