Inconsistency in error codes vs exceptions

[eugene-kulak]

It is not clear why query throws an exception in case of error, but command not, so the user has to manually check the return code.

[iwongu]

Sorry for the late response. Which places are you mentioning? I tried to use error codes everywhere except for the methods that cannot have return values such as constructor.

[eugene-kulak]

@iwongu for example command.execute you need to check return code.
It is weird to see both, and I think worth to mention in examples (I didn't know that my commands not working)

[snej]

I agree, it's very inconsistent. It's OK to have an API that doesn't use exceptions, but it should not use them at all, even for constructors. (Yes, that makes constructors awkward and a lot less useful. That's the price you pay for not using exceptions!)

Having some of the API return errors and some throw exceptions is kind of the worst of both worlds. Projects that don't allow exceptions can't use the library, and projects that do use exceptions now have to add a bunch of if (err) throw... gunk around most of the calls, or else if they forget to do so they'll silently miss an error.

My vote would be to change the entire API to consistently use exceptions.

[iwongu]

While a full API overhaul was avoided to maintain backward compatibility, PR #82 improves consistency by ensuring that critical operations (like move assignments and command preparation in constructors) correctly throw database_error when they fail. The new test suite in headeronly_src/test_all.cpp also explicitly documents the expected throwing vs. non-throwing behavior for various classes.