Error Handling
Closed this issue · 5 comments
In PR #1, @tomaka states that "handling bad input should ... be considered as a normal situation that this library handles."
I then go on to describe my attitude towards scale-ts's error handling).
... this library will not be utilized directly by end developers. The combination of transcoders will either be (A) derived at runtime based on FRAME metadata or (B) codegened at build-time. Encoding/decoding errors will always indicate invalid derive logic or broken codegen... not faulty transcoders. My goal is/was to add more fixtures (another point to discuss) to give us confidence that the transcoders behave EXACTLY as do their Rust counterparts. Given valid input, the enoding/decoding should never fail.
@tomaka then goes on to state:
"It's not you who decides that end users will not use this library. It's here, public, in the open."
... this is a great point. So I'll leave it to you community! Do you see fine-grained errors as an important feature, or as bloat? Will you be using this library directly, or only as it's abstracted over by other tools? Any feedback would be appreciated.
I imagine this will become clearer as more projects begin to fork and apply the repo to their own use cases. Perhaps after a period of time host a Google Form in an attempt to get a clearer picture of the overall consensus, and apply changes if warranted.
Just want to point out again that the changes are literally 4 to 5 lines of code. It's just about adding a throw in the union decoder, in the compact-scale-encoding decoder, and another one I can't recall.
Personally a library that assumes that input is correct is a major red flag and if I see this I will just straight up lose all faith in the quality of the library and not use it.
@tomaka two thoughts:
- if (A) there's an explicit contract (valid input -> valid output) and (B) that contract is upheld, trust/faith is unbroken
- To me it seems there are dozens of cases for which we'd want to assert correct behavior. Were specifically do you want to see error checks / messaging? If it's truly a 4-5 line change, let's do it!
Were specifically do you want to see error checks / messaging?
Just at the places where I left comments in #1
It's my intention to revisit the errors mentioned in #1 –– will hopefully get around to this soon!