How do I handle invalid values ​​passed to the setter method?

Question

If I have a simple class, for example ...

class Rectangle { private: double length; double width; public: void setLength(double l) { length = l; } void setWidth(double w) { width = l; } void getLength() { return length; } void getWidth() { return width; } void getArea() { return length * width; } }; 

... and the person using it calls the setWidth () mutator with an invalid argument, say -1.0, what is the correct way to handle this? When I say correctly, for example, should I change the type of the return value from void to bool or, possibly, to int, and return a value to indicate whether the operation was successful or should I allow the value to be set, since in theory this will not break nothing, but any values ​​returned as a result of, say, from getArea () will be garbage, and the user will have to debug what he / she did wrong?

Sorry if this is a stupid question, but two text books are later, and I'm still not quite sure how the classes that I write should be implemented for other users.

Answer 1

You have a couple of options. In the real world, this will depend on who uses your class (another internal code or public API), as well as agreements agreed by your company.

You can:

Throw exception

Pros:

• Simple implementation
• Keeps error handling code clean
• Allows you to send error messages and other variables
• Standard for most exceptions
• Difficult to ignore than boolean return
• Can be selected from the constructor

Minuses:

• May be excessive in areas where conventional conditional statements should be used (this situation is not taken into account)
• You enter more "invisible" breakpoints in the application. Many times, class users don’t know what they’re about to quit because they are either not documented or have not read the documentation.

Approve

Pros:

• Rule: if you are going to crash, early early
• Good for situations where you, as a developer, call code and control input.
• Strong debugger support (usually)

Minuses:

• It gets an exception from non-debug collections, which is not very good for cases when the user can still enter bad data.

Boolean values

Pros:

• Fast / easy to use
• Less footprint than exception handling (although this is negligible these days).

Minuses:

• Unable to transfer additional information to the caller (why did he break?)
• It is interrupted when you try to be consistent throughout the project, and a simple logical object will not cut it
• Easier to ignore compared to exceptions

Calculate data type

Do not be afraid to come back and check if the data type of your property makes sense for what you are doing. In this case, it is. However, I can think of times when developers used standard integers, when they really needed unsigned integers or strings, when they really needed a single character.

Answer 2

You should throw an exception:

 #include <stdexcept> // ... void setLength(double len) { if (len < 0) throw new std::invalid_argument("len"); length = len; } 

Answer 3

Depends on the use of the class.

If you want to pass a friendly message to the user, you can set an if and throw exception (for example, std::invalid_argument ) with a good description. Of course, update the documentation and signature.

If you expect this to never happen in real life, but, say, the development testing phase may happen, then I recommend using assert . As in the production / release assembly, statements are "removed" from the code by the compiler. Therefore, during testing (debugging, for example, -DNDEBUG and / or -g option for gcc), if someone made a mistake, you will see an explicit rejection of the statement, but in the real / production environment no error messages are reported, and additional conditions won't hurt performance.

Normally, when the compiler is called with the -DNDEBUG option, it

Some links for assert and throw syntax.

Answer 4

Or return false; , or throw something like invalid_value .

Answer 5

How the error should be handled is entirely up to requirements / projects. If your project needs to continue with incorrect user input (which can be very dangerous in real software), what you need to do. Similarly, if a project needs to be protected from incorrect user input, this should be eliminated.

When creating a class that will be used by another user, you must make sure that it cannot be used in any wrong way. You have to trick your code. If an error occurs from the software in which your class will be used, you must write the class so that the error does not exit your code.