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.
