I often run into this problem, especially in Java, even if I think it's a general OOP issue. That is: raising an exception reveals a design problem.Suppose that I have a class that has a String name field and a String surname field.Then it uses those fields to compose the complete name of a person in order to display it on some sort of document, say an invoice.public void String name;public void String surname;public String getCompleteName() {return name +   + surname;}public void displayCompleteNameOnInvoice() {    String completeName = getCompleteName();    //do something with it....}Now I want to strengthen the behavior of my class by throwing an error if the displayCompleteNameOnInvoice is called before the name has been assigned. It seems a good idea, doesn't it?I can add a exception-raising code to getCompleteName method. But in this way I'm violating an 'implicit' contract with the class user; in general getters aren't supposed to throw exceptions if their values aren't set. Ok, this is not a standard getter since it does not return a single field, but from the user point of view the distinction may be too subtle to think about it.Or I can throw the exception from inside the displayCompleteNameOnInvoice. But to do so I should test directly name or surname fields and doing so I would violate the abstraction represented by getCompleteName. It's this method responsibility to check and create the complete name. It could even decide, basing the decision on other data, that in some cases it is sufficient the surname.So the only possibility seems to change the semantic of the method getCompleteName to composeCompleteName, that suggests a more 'active' behavior and, with it, the ability of throwing an exception.Is this the better design solution? I'm always looking for the best balance between simplicity and correctness. Is there a design reference for this issue?  
Should a getter throw an exception if its object has invalid state?
java;class design