Timeline for Should serialization and deserialization be "atomic" transactions?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 28, 2023 at 20:52 | vote | accept | Patrick Wright | ||
| Feb 15, 2023 at 15:51 | comment | added | Matthieu M. | @bracco23: There are 2 contracts here, the contract (invariants) of RGB, and the contract of the function. The failure I referred to is about the contract of RGB (not fully constructed), and yes I do agree that TryDeserialize would NOT be failing its own contract if it fails to deserialize due to incomplete input. | |
| Feb 15, 2023 at 14:48 | comment | added | bracco23 | @MatthieuM. if the contract has std::expected<RGB> as return type, then it returning an unexpected object doesn't constitute a failure of the contract, as the contract explicitely states that possibility. To be consistent, such a function should probably be called TryDeserialize as it's expected for it to not succeed in the operation, but that still amounts to success for what the contract says. | |
| Feb 15, 2023 at 8:03 | comment | added | Matthieu M. | Note that raising an exception is not the only way to signal failure, even in C++. The deserialize function could return std::expected<RGB>, or something similar. | |
| Feb 14, 2023 at 20:13 | comment | added | J_H | Yup, yup, I'm aware. I was giving a multilingual response. In a language that can raise exceptions, DbC offers good guidance for keeping your promises. In a dynamic language there's a temptation to substitute a non-int type to show that an exceptional thing happened, and then caller will misinterpret it. In the C++ language some folks will be tempted to declare that RGB only goes to 254, with 255 being exceptional, also leading to caller misinterpreting it. The key is to preserve class invariants and only return correct answer values. If the ctor gives (0, 0, 0) and we hit EOF, don't return it | |
| Feb 14, 2023 at 20:07 | comment | added | cmaster - reinstate monica | Nitpick: Since the three members are declared uint8_t, it's generally plain impossible for them to contain anything other than numbers in the range 0-255. Those 256 numbers correspond one to one to the 256 possible bit patterns in eight bits. I.e, there is no pigeon hole left for a NULL or NAN value. | |
| Feb 14, 2023 at 1:12 | history | edited | J_H | CC BY-SA 4.0 | added 22 characters in body |
| Feb 14, 2023 at 1:05 | history | edited | J_H | CC BY-SA 4.0 | added 19 characters in body |
| Feb 14, 2023 at 1:00 | history | answered | J_H | CC BY-SA 4.0 |