All RuntimeException / Un-checked exception advocates, how would you handle this scenario?

Question

Scenario:

For a web-site which requires registration based on user id, the user id must be unique. Lets say a user has attempted to register with 'foo' user id, which already exists (with other required fields). Now, without using checked exceptions (database API will throw SQLException for duplicate insert), I wonder how advocates of unchecked exception handle this situation and intimate to the user that the id was already chosen?

Let's say this web-site is on Struts (no no, I'm not working on a project, it's just that I understand it better). User submits filled information to Struts Action which calls DAO to insert new record. So, ultimately, DAO will issue INSERT statement which will fail. So, if Action (calling DAO) does not explicitly handle this situation (DAO method may just declare that it throws SQLException or method may catch SQLException and throw a business-checked-exception like DuplicateUserIDExceptoion which extends Exception), how can this be handled with unchecked exception?

Bottom line - I read many articles stating that Java does not require checked exceptions so, this scenario will help me understand it better, I hope. Please do not point to articles as I had read many, many and I'm really very confused. The best way you can help me is by providing answer to the above scenario.

Note: I do understand that any recoverable exceptional scenario must be handled by a checked exception (which I have been implementing in my projects) but, I'm really confused by un-checked exception ONLY advocates. How do you people handle above scenario?

Thanks in advance.

Answer 1

An unchecked exception can be caught exactly as a checked exception is. I would use the following to handle such a case:

1. Check if the user ID already exists. If so, throw a checked DuplicateUserIdException. I think a checked exception makes more sense here. But you could also make the exception a runtime one, and catch it in the presentation layer as you would catch a checked exception
2. insert the user. If a SQLException occurs, it's not easy at all to be sure that it's precisely due to an already existing user ID. Plus the constraint could be checked at commit time if deferred. This exception would only occur in case of a race condition between two threads, and should thus be very seldom. So I would treat it like a technical runtime exception and display a generic error message.

Answer 2

How about starting a transaction, querying the database to check if the id exists, if it doesn't, perform the insert, and then committing the transaction? If it does exist, tell the user the id already exists. Even better, you could perform the check on blur of the username field in the form as an ajax request and indicate to them that it is already taken. Why do you want to rely on a database exception to determine if the id exists or not?