+1
> On Dec 14, 2014, at 4:53 AM, Martin Desruisseaux > <[email protected]> wrote: > > Hello all > > Thanks Marc for the feedback. > > About AbstractAutoChecker, no problem as the goal sound nice. I suggest > to just move them in some internal package until the API settle down. We > can move it back to a public package (it can be logging, or other) once > the API look fine. > > Martin > > > Le 14/12/14 18:47, Marc Le Bihan a écrit : >> => The goals of these (yet still incomplete) classes are not to log >> messages, even if they are doing this too, it's to grant the objects >> inheriting them the ability of auto-checking themselves, and if they >> find some troubles then, to list all the errors, warnings they can >> find and not only the first one. But, I have not put the parts doing >> the auto-checking of the objets yet and I understand really well why >> find these classes gruesome ! I am really sorry ! Soon I will complete >> these classes. >> The overall idea of these classes is to allow the API to check an >> object entirely before doing something important with it. Most of the >> time, I use this feature before inserting or updating a business >> object into a database. I ask, for example, my Customer object about >> itself : "Do you feel ok ?", if the object replies : "no, I have no >> Name" or something else, I will throw an InvalidCustomerException. >> Because if I carry a Customer object from function to function it has >> to be ok (in memory at least) : it has respect some core rules. This >> kind of defensive programming is really useful when you are reading >> business objects from a database that has not be written by you and >> seldom contains errors you cannot figure easily : you detect theses >> errors immediately. And silently or not, depending what you want. >> I will move this classes outside the log package, even if they will >> stay on utility jar. >> >> Marc. >
