Thanks for reply, Sylvain!
I definitely agree that my solution has some overhead and your is much simpler, but one of the things I aimed for was to distinguish the "critical" exceptions from the ones that can be handled by such "IF (NOT) EXISTS" extensions, so - in the end - it could be possible to let user know what really happened and, maybe, display some descriptive NOTICE message instead of displaying nothing (I was a bit "inspired" in how it's reported in PostgreSQL in similar case). However, if you say it's not necessary, I'm fine with it
Additionally, in most of the cases validation checking if KS/CF/Index exists (or not) happens outside *Statement classes (for example for CFs it's done in MigrationManager.announceColumnFamilyDrop()) and I didn't like the idea of passing additional parameter and handling it there - I preferred this decision (if exception should be thrown or not) to be done by *Statement class itself, basing on what was returned/thrown by MigrationManager.
One thing I missed when coding was the fact that for KS/CF, when reporting existing / inexistent KS/CF, ConfigurationException is thrown (index-related code throws InvalidRequestException, which looks like a little inconsistency to me, by the way), so I could have reused it, instead of creating new ones.
Anyway, I see your point Tomorrow I'm leaving for three weeks and when I'm back I'll reimplement it taking your suggestions into account