Ideologically correct setter?

Question

Programming

Imagine a situation - there is some class, for example Subscriber, which has a private field string Subscriber::email and a method that sets its value Subscriber::setEmail(string val).
Obviously, you can try to set an incorrect address through this setter (for example, not containing the @ symbol).
Question: 1. Should this setter check the correctness of the soap?
2. If so, how should it signal incorrect input?
Through the return value or through the exception?
PS Please take into account the following arguments:
+ each method should be responsible for one action, and in paragraph 1 we are trying to assign to this setter both the value check and the field setting.
+ if you still try it out, and force the method to return false when you try to enter an incorrect soap, then you will have to write every time if (!s->setEmail("blah-blah")) {...} - somehow this too much, I think.
+ An exception should be thrown when the error cannot be corrected in the place where it was found. This usually happens with a large nesting of the function call stack, but in our case, the exception seems not entirely appropriate.

Answer 1

Must check for correctness.
At the same time, he remains responsible for one action - for setting exactly email'a, and not an arbitrary string.
Therefore, it should also generate an exception for incorrect data.
The method is called setEmail for a reason.
You are not surprised that when you try to assign a string to an integer field, you get an error (probably even compilation).
The exact same thing happens here.
If we talk about ideology, then it's even better to make an Email type and do checks in it. But in normal, not ideal code, this would almost certainly be overkill. Therefore, checking in the setter is a good compromise.

Answer 2

It all depends on where this setter is available. There is an approach with the separation of safe and unsafe areas. If you have a UI in your application and the data comes from it, then the UI code should check if the email is valid, and the setter should set whatever it is given. If this setter is available to the user or some third parties, then you need to do this check inside the setter and then you need to look at how the error response is usually handled by other methods. If exceptions are everywhere, let there be exceptions, if False is returned everywhere, then it is possible and so. If this code is only for developers, then you can assert in the debug, and throw a big and terrible exception in the release (but only if the incorrect data comes due to the curve of logic,

Answer 3

> each method should be responsible for one action
It is not necessary to understand everything so literally. For example, you should not connect to the database, select information, upload results back and merge information into the log with one big sheet in one function. But this does not mean that every simple operation (such as assignment) should be moved to a separate method.
> and in our case, the exception seems not entirely appropriate.
The exception says "I can not execute the command", in this case we do not allow incorrect input. Do not be afraid and save on exceptions, this is a convenient mechanism (up to such tasks as stopping map(), but this is already a matter of taste). No matter how deeply "nested" the call to your function/property is, you don't really know and can't know.
Yes, your setter must validate the input and assign the value if it's edible, otherwise throw an exception.

Answer 4

blog.byndyu.ru/2009/10/blog-post.html
Start reading from 2. Data validation.
here for an example.

Answer 5

As I understand it, you are more concerned with the question of when and how to check for validity? Personally, I really like the concept of barricades. Especially if you have it all deep in functionality. Just filter incoming data early on.

Answer 6

And why the address should be a string. Let it be a separate class, with internal validity check.
Subscriber::setEmail(EmailAdress val)
And already in the setter of the EmailAdress class itself, make a check.

Answer 7

> 1. Should this setter check the correctness of the soap?
No, it shouldn't. A data integrity check must be performed before performing a critical action.
However, why then such a simple method?
You might as well just write:
$s->email="[email protected]";
Setters and validators should live separate lives.

Answer 8

Rails does the check directly on save. And they do it right. Errors are transmitted to the system, then they are displayed directly to the user.