This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Taking an SOA approach using EJB's. Client code calls a method to retrieve a list of objects. If the client passes in invalid criteria, we would like to return messages regarding what is invalid. However, if the call was succesful and has objects in the collection we would just like to return the collection of objects. We could: 1. Return a complex object that contains a collection of objects and a collection of messages. The client would then need to try to retrieve the collection from the complex object (extra step). If the collection is empty, the client could retrieve the collection of messages to find out why the collection is empty. 2. If the collection of objects is empty, throw an ObjectNotFoundException, even though having an empty collection may be a valid scenario. Our "custom" exception could contain a list of messages.
3. Just return the empty collection, and let the client figure out what went wrong.
On success, just return the collection (populated or empty).
On failure, throw an exception that contains the collection of messages.
This sounds too obvious an answer. Am I missing something ?
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Joined: Nov 08, 2004
Thanks for the Reply Ken. Are you suggesting that "success" is a succesful call to the EJB, and "failure" is when an error occurred calling the service? I guess part of my question is when is an exception an exception? Here's a more detailed example (may or may not help) . A client requests a list of dishwasher manufacturer's for the country of Romania. In our application, we have no dishwasher manufacturer's for the country of Romania. We would also like to send a mesage back to the client saying "No dishwasher manufacturers for the country of Romania." Our application, could: 1. Return a empty Collection, since the call to the service was really successful, and let the client examine the collection, see it is empty and then deal with it. 2. Throw a checked exception that contains that contains the message. This would force the client to "deal" with the fact that the collection is empty, even though the call to service was really successful and no error occurred in the service execution. 3. Throw no exception and just return a DTO object that contains an empty list of dishwasher manufacturer's and a message string that contains "No dishwasher manufacturers for the country of Romania." Thanks, Fran
Originally posted by Fran Hesser: 1. Return a empty Collection, since the call to the service was really successful, and let the client examine the collection, see it is empty and then deal with it.
I would do exactly that. After all, finding none isn't exceptional - it is a totally valid answer, and it's easy for the client to handle specifically if he wants to.
Also, messages shouldn't be the responsibility of the server - different clients could want to present different messages to their users (or react by playing a special sound, using a different color etc. pp.) - and you neither want your server to know about that, nor your client to need to parse a string to find out.
So just returning an empty collection sounds like the best solution in this case.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Nov 08, 2004
Thanks for the response Ilja. That's the direction we were leaning.
We have many interfaces to partner systems over different protocols. At that layer an exception means a communication failure ... MQ-Series, SQL, HTTP or whatever. Anything that gets to the partner system and back is good. A result like "contract not found" might be a business disaster or it might not so we can't decide in this layer to throw an exception or even call it an error.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi