I sometimes get the idea you are mixing up the assignment part and the create-an-api part (e.g. your remark about code in Andrew's book: putting null in the transfer object blows the thing up, I'll comment on that one further down in this post). These are completely other things.
You (always) have to make a distinction between what's needed for
a) the assignment
b) creating a developer-friendly API which can be used by other developers
For a) you don't need much: some client side validation to ensure a correct port number for the server and a correct customer id. And that's really all you need, because the user can't do much more. So you can develop your complete code with almost no validations (like in Andrew's book). You really don't need more, because you develop the application and you'll make sure you don't pass a wrong String[] to the update-method for example.
For b) you need a whole lot more, because you want to give a developer who is using your API some guidance when he makes a mistake in using your API. So you add some checks in your Data class, e.g. when a method is called before calling the init-method, when he passes a String[] with not enoguh elements, when he calls lock-method 2 times,... Each time the developer wrongly uses the API he will get some IllegalXxxException with a little description about what to do. These exceptions are not meant to be caught, because they are only thrown when a developer makes a mistake (and that should not happen anymore when the application is released) and the user of the application will not be able to do something to solve the issue (except waiting for a next release with a bug fix).
And of course you as API designer and developer decides how far you are willing to take this extra work. But I myself hate an API which throws a NullPointerException and I have to take a look at the source code (or even decompile the class file) to get an idea why I got this unexpected exception. Therefor I put a lot of effort in making my API as developer-friendly as possible. This should also make it easier for a junior programmer to make changes to your code. But that's not something which is required by the assignment.
That's just my view on things and sometimes people have difficulties in making the distinction between these 2 parts.
Sean Keane wrote:I was just looking through the code from Andrews book and he does no validation at all that I could see at the server side. I haven't tried running it by sending null's in the transfer object, but from a quick glance at the code it looks like it would just blow up with a null point exception.
From the assignment point of view that's not a problem at all. Because he was the developer, so he knew passing nulls in the transfer object is not a good idea and he didn't do it when developing the application. When a user left the input field empty, he passed an empty string to the transfer object. If of course he made a developer mistake and passes a null to the transfer object, the application might crash during assessment which is not a good thing

From the API point of view that's a poor API, because you'll get a NPE and you don't know why. But let us assume he made his API more developer-friendly throwing an IllegalArgumentException when you set null in the transfer object. When he makes the developer mistake again in this situation, the application might crash during assessment (with another exception of course), but it's still not a good thing and will affect your score

So although he added some validations, the program still blew up because he made a developer mistake (and didn't
test his application enough)
Sean Keane wrote:So where do you have all this "clutter" with the checks? Do you have them in a separate class and you call that from the update-method? Or is that validation carried out before the String[] array is passed to the update method?
Nothing to fancy: just a seperate private method in Data class, which is called from other methods
Sean Keane wrote:I hadn't stuck any in yet, but thanks for the tip about the record number :-)
It's the customer id
