This is quite ugly (hopefully obvious) and is somewhat oxymoronic, but one must concede at this point - the language is quite broken.
2) The code will quickly become extremely verbose - again I hope this is obvious.
"Simply the 'get' method has two return values: one is an exception, and the other is a X. When the client uses this method, there will be two alternative path executions implied by a try/catch block."
Originally posted by Stan James:
I just don't know what to do with this:
is it I'd rather live with the problem. You railed against "marketing" influences but maybe you need some ... try selling this to me again?
To Manish's original post, I like the questions raised. Try thinking only from the consumer point of view for a while. When you call an EJB or a DAO what do you want it to tell you and what will you do with it? Imagine that your services change from EJBs to some other protocol, or your DAOs change from database to web service calls. Wouldn't you still be interested in the same things?
Then ask if this point of view is sufficient. Can a DAO predict what all future clients will need to know?
Does that spark any ideas?