Object-level validation vs validating user input

[iskandarzulkarnaien]

From what I know, there are two main ways to approach error handling. Object-Level validations (raise exception in constructor) and validating user input (in whatever class handles user input).

Seems like the general consensus from this Stack Overflow question is that object level validation is the "right" way to approach things from an OO perspective (e.g. one response reads "The constructor should always return an instance which is in a valid state. There is no excuse for doing otherwise.") as you are more likely to accidentally create a god class that handles everything if you choose to validate user input.

It seems that most of us chose to validate user input. Anyone have any opinions regarding this? Is validating both an excessive measure?

[damithc]

Perhaps you can give a concrete example, preferably from the iP?

[iskandarzulkarnaien]

Let's look at the Todo object for example. We could do validation in two ways:

1. Validate input before passing it to the constructor (perhaps by having a method in Duke.java raise exception if description is blank).

2. Validate user input in Todo constructor (perhaps by raising exception if this.description is null)

I'm thinking of whether option 2 would be more appropriate, since it results in the Todo class being responsible for not allowing "invalid" Todo objects to exist, as opposed to having the main class handle it or creating a new class specifically to validate inputs.

[uggi121]

If I could opine in on this issue, I'd say both approaches have their pros and cons, which you've highlighted in the above comments. While Object-Level validations align with the essence of OOP, it could be a bit tedious to deal with similar cases in multiple objects. This will ultimately lead to a lot of redundant and repeated code.

A partial solution could be to handle common cases like white-space/empty inputs at the input-class level, leaving the object constructors to deal with more specific invalid inputs relevant to their associated objects.

To add on, we could abstract the input class at a higher level to a machine that accepts input. The machine has no idea what the valid input for other machines (objects) are. However, there are certain inputs that are invalid inputs for ALL objects. These can be handled at the input class level.

[iskandarzulkarnaien]

Thanks for the response Sudharshan, really appreciate your contribution to the discussion.

About the input class, that makes a lot of sense. It just acts as a filter to remove inputs that are obviously gibberish or incomplete, while the respective objects deal with whether the input is "correct" (e.g. startTime < endTime).