It seems to me that in your example the two exceptions are exceptional. ie. you don't expect them to be thrown very often.

The problem with the overall pattern is usually you DO expect validation checks to fail.

I would code this up the same way you have. But I would in additon have code which performed the same validation checks before submitting the creatr user request.

These checks would not throw exception, they would return a list of human readable validation failures, with enough meta data to enable highlighting of problematic fields etc.

Sure I need to recheck when the actual request comes through, in case of race conditions. But that is now an exceptional and unlikely event. I will just log it and tell the user "error, please retry"

It seems to me that in your example the two exceptions are exceptional. ie. you don't expect them to be thrown very often.

The problem with the overall pattern is usually you DO expect validation checks to fail.

I would code this up the same way you have. But I would in addition have code which performed the same validation checks before submitting the create user request.

These checks would not throw exception, they would return a list of human readable validation failures, with enough meta data to enable highlighting of problematic fields etc.

Sure I need to recheck when the actual request comes through, in case of race conditions. But that is now an exceptional and unlikely event. I will just log it and tell the user "error, please retry"