Closed alovak closed 10 months ago
Patch coverage: 68.29%
and project coverage change: +0.20%
:tada:
Comparison is base (
8252a73
) 73.50% compared to head (c54575a
) 73.70%. Report is 7 commits behind head on master.:exclamation: Current head c54575a differs from pull request most recent head 828c2f1. Consider uploading reports for the commit 828c2f1 to get more accurate results
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
What do you think about creating a NewMessage
version with error return? If someone wants to handle it on that way. (Speaking about my own case mostly)
For exmaple:
func NewMessage(spec *MessageSpec) *Message {
message, err := newMessage(spec)
if err != nil {
panic(err) //nolint // as specs moslty static, we panic on spec validation errors
}
return message
}
// NOTE: I don't know what would be a good name for that
// NOTE2: There should be an explanation about backward compatibility
func NewMessageWithError(spec *MessageSpec) (*Message, error) {
return newMessage(spec)
}
func newMessage(spec *MessageSpec) (*Message, error) {
// Validate the spec
if err := spec.Validate(); err != nil {
return nil, err
}
.
.
...
}
Let me know what you think about it.
Also, it closes #269, not #270. :)
When you define spec, it will panic if you have a composite field with invalid spec. So, panic
happens before NewMessage
.
Panicking in Go is generally reserved for situations where it's inappropriate or impossible for the program to continue. In our case, if the spec is not valid, we can't proceed. I believe using panic
is acceptable.
When you define spec, it will panic if you have a composite field with invalid spec. So,
panic
happens beforeNewMessage
.Panicking in Go is generally reserved for situations where it's inappropriate or impossible for the program to continue. In our case, if the spec is not valid, we can't proceed. I believe using
panic
is acceptable.
By default I agree on that usage of panic and I'm not trying to push my point of view, but I would like to share some argument to add an exported function with error return. (Note, I don't want to remove the original behavior, I'm just suggesting a minor extension)
First I would like to highlight the usage of the library. By following the original documentation located in the README, we call the message := NewMessage(spec)
with a specification defined as JSON and marshalled into the struct representation. We do that every time when we build a new transaction request and also we do that when an incoming message arrives. We do Unpack
and Pack
.
Based on these arguments I hope you can reconsider the suggestion above.
I want to understand what you're asking us to reconsider. Are you asking that methods like NewMessage
and SetSpec
return error
instead of panic?
@adamdecaf I had this comment on this pull request.
@adamdecaf
Sorry I just answered quickly. By following the previously linked comment, I would like you to reconsider that you add an exported function which implements the same as NewMessage
, but it returns with error instead of panic. I'm not the best in naming so I mentioned NewMessageWithError
, but obviously it's not the best. Based on the reasons and arguments from above, this makes the user of the library able to decide whether the program can handle a panic in case of any issue or they want to handle it themselves by using this new exported function.
The main issue with the NewMessage that it has a lots of unexported part. So I can't write a function which is not relying on panic.
Also I understand if you don't want to add such a change, but I thought I try it. :)
I don't think supporting backwards compatibility of panics is something we want to support. Causing a panic
is very expensive and dangerous to systems. Callers can still panic if they wish, but our libraries always try to avoid that.
I don't think supporting backwards compatibility of panics is something we want to support. Causing a
panic
is very expensive and dangerous to systems. Callers can still panic if they wish, but our libraries always try to avoid that.
I don't want to pick a side in this question, I just offered a possible solution where the caller of the library can decide between the backward compatible way or using another function with error return.
Otherwise I wrote a wrapper solution to avoid panic for our use-case. So I'm also fine with the current implementation as well.
Closes #269
With this PR we:
Validate()
method forMessageSpec
andfield.Spec
- so if you don't want constructor to panic, you can validate your spec before.StringsByHex
if sorted value is not a Hex, we compare them as regular strings (nopanic
)panic
in fuzzer, I hope later we can address it