On 2014-08-21 12:32, Bjorn Reese wrote:
On 08/19/2014 02:49 PM, Roland Bock wrote:
If I understand you correctly, you should be more happy with the current implementation then: As of today, depending on the compile-time configuration in the connector you have the following possible behaviors:
You can always check for NULL by calling is_null. But if you ignore the outcome and try to obtain the value of a field which happens to be NULL
Variant A: an exception is thrown Variant B: the "trivial" value is returned, 0 for numbers.
The Variant is chosen at compile time.
I find it a bit worrying that this behavior is changeable at compile-time, as it makes reviewing and reuse more challenging. The decision is taken in the connector class or the respective column. If you change those, you will have some effect.
Also, it would be easy to make your code break at compile time if you switch between A and B. It already breaks if you use B in the typical way (see below) and switch to A. Thus, you would not get nasty surprises after compilation.
With optional<T> you will get variant A. If you want variant B, then you use optional<T>::value_or(). This makes your intent clear in the code.
_Variant A is (as of today):_ if (!row.alpha.is_null()) { int a = row.alpha.get_value(); } else { // something else } _Variant B is:_ int a = row.alpha; The conversion operator to the respective value type is not available in Option A. I am using Variant B all over the place. If I had to change all that into int a = row.alpha.get_value_or(0); I would have to add kilobytes of noise, lowering readability, IMO. Since I personally do not use Variant A, I am open for suggestions, of course :-) Cheers, Roland