Always provide an explicit case in a switch

[zauguin]

This avoids having a switch without a case by being more specific withthe default: We expect the default to be hit mostly by errors of the form SQLITE_ ## NAME, so we can specify an explicit case for this.
This is no functional change, but it might explain better what is going on.
AFAICT this would stop Visual C++ from complaining.

[zauguin]

This would also close #166 which is an alternative fix for the same problem.

@aminroosta @vadz @RunningWithScissors- Which version do you prefer? I personally like this one more, but I am not sure why so it might just be a case of the not-invented-here syndrom.

[vadz]

FWIW I agree that fixing this at the code level is preferable to disabling warnings, but I don't know this code well enough (or at all, to be honest) to know which one of the proposed fixes is better. This one seems to be a bit more clear but I'm not even sure why do we need default here at all -- shouldn't be the value of error_code always be SQLITE_XXX when there are no extended codes?

BTW, on a somewhat related note, why is this int error_code being passed by const reference instead of by value here?

[zauguin]

@vadz

... I'm not even sure why do we need default here at all -- shouldn't be the value of error_code always be SQLITE_XXX when there are no extended codes?

To quote the SQLite documentation about result codes:

The names and numeric values for existing result codes are fixed and unchanging. However, new result codes, and especially new extended result codes, might appear in future releases of SQLite.

So when SQLite adds a new extended result codes the library does not know about yet, the default allows us to do the most reasonable thing: Throw the exception corresponding to the primary error. The alternative would be to ignore every error we don't know about (we certainly don't want this) or throw a fully generic sqlite_exception ldiscarding the information we have about the primary error (why should we?).

Another reason are compiler warnings: While we might know that there are no other possible values, some compiler would probably warn about a non-exhaustive switch.

BTW, on a somewhat related note, why is this int error_code being passed by const reference instead of by value here?

Good point, I don't think there is a reason. You could create a pull request against the dev branch 😉