Sooner or later in your programming career you will be faced with the dilemma of validation and exception handling. This was the case with Patkos Csaba and his team also. A couple or so years ago we reached a point when we had to take architectural actions to accommodate all the exceptional cases our quite large software project needed to handle. Below is a list of practices we came to value and apply when it comes to validation and exception handling.
When they started discussing their problem, one thing surfaced very quickly. What is validation and what is exception handling? For example in a user registration form, there are some rules for the password (it must contain both numbers and letters). If the user enters only letters, is that a validation issue or an exception. Should the UI validate that, or just pass it to the backend and catch any exceptions that my be thrown?
They reached a common conclusion that validation refers to rules defined by the system and verified against user provided data. A validation should not care about how the business logic works, or how the system for that matter works. For example, the operating system may expect, without any protests, a password composed of plain letters. However they want to enforce a combination of letters and numbers. This is a case for validation, a rule they want to impose.
On the other hand, exceptions are cases when our system may function in an unpredicted way, wrongly, or not at all if some specific data is provided in a wrong format. For example, in the above example, if the username already exists on the system, it is a case of an exception. Their business logic should be able to throw the appropriate exception and the UI catch and handle it so that the user will see a nice message.