Say, you pre-validate if a username already exist in a registration form in the application layer. E.g., You send back a nice "username already exist" error message to the user.

While unlikely, there's still a possibility that two different users can "simultaneously" pass the application layer validator and one of them will eventually get a "duplicate entry" exception from the database layer.

In this scenario, is it good practice to still catch the database layer exception and send back a nice error message to the user. Or, is that overkill, and you just let it "slide" and halt the application with a 500 error?

Note: letting it slide may also trigger your 500 error alerts, if any, at 3AM for what is actually just a "minor" validation error :-)

I know this is an unlikely scenario but still can happen, what's your approach on it?


This is known as a Time-of-check to time-of-use problem. I think the answer is by and large "it depends". Are you writing an internal application for 50 users or are you writing the worldwide user service for a massive multiplayer online game?´

Generally I would ask developers to correctly address corner cases when known at development time, as part of the feature development effort. Isolated, issues like this can get harder to get money spent on after the product has shipped. And even then you would rely on having a process where issues in production are root caused and issues filed.

If pressed for time, I'd rather leave out the preflight check and make the on-create exception handler the only error path.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.