Should the message header decoder throw an exception on a Postgres exception?

[KayEss]

It isn't yet clear what the right behaviour here is. By throwing an exception it also isn't totally clear that the connection get ever get back into a state where another command can be issued through it. This is probably going to be needed for transaction rollbacks, and maybe other things.

What is a better idea here?

[jtv]

Sounds as if perhaps you want the message-header decoder to return an error, so that the higher-level code can choose to throw — after first getting itself into a sensible state in case the connection continues to get used. I wouldn't worry about the performance cost of getting back to a sensible state. "I want to fail really really fast all the time" is a pretty esoteric requirement.

If the header itself is incomplete or unintelligible, that's a different matter. In that case the header parser can't meet its postcondition and the connection can't get back to a sensible state, so bailing out is the only course of action.

[KayEss]

I agree, so enter the monad :)

I think std::expected is going to be the way to do this, but that's held up in committee about wanting a full monadic solution, so that could be a while. Still, it'll be easy enough to write something that behaves the same way.

I think the header reader probably isn't where this ought to go. The code that decodes the packets needs to include the error packet type in their expectations -- this is likely to lead to a lot of code that doesn't handle errors very well though. I suspect that it should probably be like that nonetheless, together with a few places where trying to continue will throw.

The first thing I really need to understand I think is how the message flow changes after errors in a few places.