User Friendly Error Reporting

The notorious situation: a duplicate key exception. Users register themselves using fancy nicknames.This often leads to conflicts. In addition, as I point out in error reporting -- to except or not expect or return, the conflicts can not be prevented in a distributed environment (one ensures that there in no such name and still can get a concurrent conflict). For these reasons, the apps should be prepared to the conflicts. The cases to which apps are prepared, are not exceptional.

Meantime, if the engine insert process fails things naturally, we get an exception with a message like "Violation of UNIQUE KEY constraint 'col_name'. Cannot insert duplicate key in object 'table_name'. At first, it is not quite informative. Customers prefer to see something like: "a user with such a name already exists". Additionally, as explained in the referred topic, exception processing is extremely CPU consuming and should be not normally used as a function "feedback" tool.

The option to prevent the exception raising by preceding the INSERT op by a table-locking SELECT is not attractive either because of 1) locking and 2) double checking. Obviously, we get the conflict exception on INSERT because the DB engine precedes the insertion by a select. How it would check the existence of the same key in the table otherwise? I want to say that the only thing we should do is to override the default DB error handler.

How do I know that the error was caused by some specified constraint violation letting other issues to fail naturally? Should I parse the exception message looking for key_name?