Can you add the keyword "noexcept" in get/set methods?

Question

Is there any problem in adding to keyword noexcept in methods getters/setters of a class that only returns or changes values of simple variables (bool, int, float, double, etc..)?

Answer 1

There could always be a problem with adding something if you don’t know what you’re doing. And it’s always a solution if you know.

I imagine you at least know why noexcept exists. And I hope you know what exceptions are often abused, and it is only right to use when there are exceptional situations.

Do you think a getter, that is, a simple method that should return something should throw an exception? We usually say no, but it is only guaranteed that it will always be simple. If it can become complex it may be that some exception is thrown, for example if the access to the data comes from a database. A Setter this is already less true because it is common to have a validation. Even so in simple cases it is recommended to avoid the exception.

If these methods are used as access to properties one should generally prohibit the use of exception because it practically functions as access to the variable. In this case the correct semantics is never to throw exception, so it is even indicated that put the noexcept thus became a formal commitment in the code.

In methods that happen to be getters or setters, but that make complex things that it would be natural for an exception to be launched so even if not launch now may need to launch later and then it is better not to give this guarantee.

Actually there are two things there. Especially in C++ getters and setters are much less used, the (real) programmers of this language are at a higher level than the so-called programmers Nterprise and understand that they are not as useful as they are and because they were invented, then they know that they should not use as other programmers do. But they also know when to use it. Even, contrary to what people say, it goes against the basic precepts of object orientation. Not that they’re forbidden, but in the way they do, it’s usually wrong.

Another is that in C++ one avoids too much the use of exception, usually it is an intrusive mechanism. It is more common return an error. Usually something not to make a mistake in a moment and then go wrong is enough to have to change everything in the software, so the contract should be very well thought out before doing. That is the secret. If there is a chance that one day a mistake will be possible when you may not have it now it should already have predicted. If you make an error return, the signature of the method already has to be prepared for this and will always accompany you, even if in fact it never actually makes a mistake. The choice of exception is the same thing. If you think that one day you may have the signature you should reflect that, and then use noexcept would be wrong, even if an exception is not cast.

Some people should think that the exception is a blessing because unlike the error return you must ensure that the contract is correct, it can be put only later because the noexcept it is not mandatory, there in doubt the person makes a choice, possibly wrong, for who knows to be protected from it. And will often resolve the issue except when it is not suitable because it is made easier than changing the signature of the function. That is, one mistake after another for abuse of the mechanism and ignorance of the correct concept.

Exception is always more problematic than people think, it has implications that "nobody" sees. It is also true that in general people today make software so uncompromisingly, without quality that it is no longer important. No wonder that even being a more difficult language, codes made in C++ usually have less bugs other codes, precisely because programmers are more committed to understanding what they are doing. Everything has an exception (sorry for the pun).

So you have no problem using the noexcept, You do know what you’re doing, right? Not to use is not to fail to make a decision, it is to make the decision that can have exception, and this complicates all other decisions about the code, about the optimizations that the compiler can make.

And you know that it is not just a matter of your method to throw exception, if it calls some function that can throw exception it can automatically throw exception. And then put noexcept is a mistake. Hence we notice how important it is because it helps you define a new method that uses something inside it whether you will have exception or not.

Answer 2

Of an answer in a similar question on Stack Overflow:

Place noexcept is a bit compromising. If in the future you depend on changing the return type of this function to one that can throw exception (std::string, for example, that the original author points out) may end up breaking the code base because at some point someone assumed that its function would not launch exception in any case.

Basically, just add noexcept if it really makes sense and bring some gain ensure to those who use the function that it will not cast an exception.

In the case of these getters and setters, it is almost redundant to put, so I would say that there is no problem to put. It will only serve to make you write more and may break something if you decide to use some kind of wrapper (will you decide to use one BigInteger?) for values, but not like we go around playing blocks try/catch at getters as well.