It is better than throwing a generic RuntimeException, but it is still not a checked exception. And this could mean that a client application could die a horrible death even though the programmer coded to specified interface.
Originally posted by Andrew Monkhouse:
You cannot throw a checked exception if something fails to validate - I dont think a RuntimeException is the correct response to invalid data.
From javadoc:
Thrown to indicate that a method has been passed an illegal or inappropriate argument.
..., but because the data must continue to be manipulated for reports using another custom-written application, the new system must reimplement the database code from scratch without altering the data file format.
Originally posted by Ta Ri Ki Sun:
Alright then Maksim, given that, your clients can change the date and book rooms in advance or in the past, its a small hole, but better to plug it.
so your server returns these, but surely your server doesn't need these sent back to it in order to book a room right?
which "current system date" is that
It depends where it called because it does nothing else as But I will move this methods to another class. RoomRecord objects are value objects and so the business logic has nothing to do there.
Originally posted by Ta Ri Ki Sun:
well my database server doesn't know business rules, so methods like bookRoom must be implemented and these rules must be considered, now if bookRoom is called in remote connection, and the _stub Adapter simply creates a new Date to compare to, then that would be the clients current system Date, so while the server doesn't know the business rule I felt it needed to provide its current date to compare against.
This was actually a bug I found when testing my remote clients, the clients could change their dates and book rooms, but remember your Data class should only update, only rules it should care about are valid parameters, and update no matter what.
Does it mean that your server/remote class has a method named bookRoom(...)? The name of the method sounds to me like a business operation or use case and therefore I would say you have to implement the business rule in this method.
(Sorry if I have misunderstood something. English is not my native language.)
Regards, Maksim
Releases the lock on a record. Cookie must be the cookie returned when the record was locked; otherwise throws SecurityException.