Closed froydnj closed 6 years ago
I think that's the right approach--do as much validation/error handling in this crate as possible, and use strong typing to make it easier for users of the crate to do the right thing. Handling malformed requests feels like it should be isolated to this crate, and when we flesh out the Handler
trait it should provide only requests with valid data, and the methods should have return types that require valid responses (errors may be valid responses in some cases, certainly).
I also think if possible it'd be great to have default methods on Handler
or something like that so that users can get up and running without having to implement a ton of things.
I'm not super-happy with
hex_value
returningOption<u64>
, but I think we have to do this to make the remote stub code robust. We should be able to handle theOption
-ness inhandle_packet
-- by returning an error -- so the actual userHandler
never knows about the error states.