Encode/decode error handling and fallback

[killthebuddh4]

My current understanding of fallback content is that

• we can of course assume any client can render plaintext
• during encoding we can specify a plaintext representation of the message payload (or it could just be a static text string)
• during decoding, if a client doesn't support a message's content type, the message's payload will be set to the plaintext representation specified during encoding

So I guess I have one question and one suggestion:

• If I'm authoring a codec, how should I handle errors inside the decode method?
• It might be useful if the client could catch errors inside the decode method and then handle the message as if the required codec had not been registered.

[saulmc]

📟 @mkobetic

[mkobetic]

Good question and suggestion. I don't think there is much a codec writer can do in the face of decoding errors, other than let the error bubble up. That should ultimately result in the Stream.next() call to throw.

I think I agree with the suggestion, Client.decodeMessage() should catch the decoding error and set the message up the same way it does for missing codec, including the fallback. That way the error is still visible to the app and the fallback is available as well.

[killthebuddh4]

Awesome, thanks for the reply @mkobetic. @saulmc Is this a situation where I should go create an issue for the suggestion above? Or is that something you guys will do, maybe just keeping an eye out for discussions that yield action items? Or maybe neither?

[galligan]

@killthebuddh4 would love to see more issues generated by the community, so by all means kick it off! Always great to plant that flag in the ground.