Question

When invoking a method in server side I can get a list of errors or warnings if something is wrong with some of the parameters, or a correct answer if everything is ok.

For example, I send an object defined at client side to the server, where I have the logic to validate if that object is ok, so I can return a list of errors and warnings related to the object definition to the client so he can correct them properly, or, if the validation goes through, something saying that everything was ok.

Possible solution: I could return a List of Errors, so, when everything goes ok the list is empty, and when I have some errors or warnings I can handle them and show them to the user.

Is this approach correct? Is there any design pattern to do this in a better way? My background is a client-server architecture and I will be using EJBs invoked from client side using Business Delegate pattern to design the communication.

Answer 1

If the client is able to send objects to EJBs, then it’s probably a client written in Java. So it’s in fact a rich presentation layer that invokes the EJB methods. If so, then the validation should be done in this presentation layer, IMO.

It might be desirable for the server to add an additional layer of validation for its own safety, but in this case, since the contract of the method is well-defined and the presentation layer is supposed to validate the objects and respect the contract, I would just throw a runtime exception at the first error found.

If you really want to perform the validation at server side, I would use a checked ValidationException to signal a list of errors. This exception could contain a list of messages, or a list of message keys with associated parameter values. That would depend on the necessity of internationalization (i18n), and who is responsible for i18ning the messages.

Warnings can also be put in this exception (the message would then be associated with a flag or enum). If the client invokes the method with ignoreWarnings = false, then warnings are stored in the exception and the exception is thrown. If it invokes the method with ignoreWarnings = true, then warnings are ignored and only errors lead to an exception being thrown.