From the DAO layer catch all Database (Hibernate/SQL) exception & throw a consistent DAOException to the EJB Layer. In the EJB catch the DAOException & throw a DomainException to the Struts layer. so on

Is this a good approach to just throw a consistent exception from one layer to the calling layer so the calling layer methods need to only catch & throw a single type of exception.

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.

What does "quite broken" mean? Nobody can do anything productive with it? If I am to adopt something "quite ugly" and "extremely verbose" it better solve some problem that's really bothering me. If

"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."

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?

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

Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

posted Jul 30, 2006 16:52:00

0

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?

Sorry I will use my marketing skills - which can be measured as some value above nothing but is not visible to the naked eye I don't wish to sell anything - just provoke some critical thought, so I'll just try a slightly different approach - there are many that all derive the same conclusion.

I won't qualify "the language is quite broken" since although it is true, is not good marketing - people don't like acknowledging truths that violate "feel good" agendas and it just causes silly arguments anyway (as a result of the need to abandon that "feel good" thing - a very difficult thing to do).

The quote that you refer to is with respect to the need to create a "quasi-closure" that is then later called back on when there is some dependency on an imperative API. I have not met anyone yet who is able to observe this effect with an imperative programming language through pure thought experiment though the analogous mathematics is quite trivial. If the need to depend on an imperative API is abandoned so too is the need for an "imperative quasi-closure".

The verbosity relates to the fact that a language that truly supports closure typically doesn't need: a) a type declaration b) a method signature c) access to locals declared final (a devastational limitation not so much related to verbosity)

Since the use of any "quasi-closure" implies this verbosity, it can become extremely unwieldly. It also means (by and definition and by force) that local declarations no longer leak and, since most Java code leaks all over the place, the verbosity goes up further. However, most of the new methodologies for using these type of languages (TDD, Agile, XP, etc.) are actually attempting to approach this without acknowledging it. In other words, the amount of code that leaks is typically "extremely high", but in some cases is just "high". These methodologies have a euphemism that is synonymous with attempting to minimise requirement leak (a thoroughly misunderstood topic) which is called "refactoring" (excuse me while I puke at that term).

Anyway, since thought experiment seldom produces a valid result for the described case, I encourage anyone to try it for a trivial case. Given a method that declares to return a type T, but for whatever reason, that type may never be returned, instead of "returning null, or throwing an exception", instead pass two closures - one typed (for the successful return path and one untyped (for the path that the value cannot be returned)). Ricky gave a case for how Haskell solves the problem with "Maybe". After I introduce this to people, often a lot of discovery takes place soon after, hence the encouragement - little time invested with a high return of knowledge.

I work for a company of 15 people who specialise in J2EE application production. All of my colleagues are very clever people (in stark contrast to my previous employer). When I first started, all of my colleagues were extreme TDD/XP/"Refactor"/<insert hyperbole here> proponents. Most of them still are. I spent many hours (hundreds? maybe a little exaggerated) with one colleague demonstrating some of this basic theory plus much more. After some time, some things became apparent, which would otherwise have appeared absurd (without time), and so now there are two people in this company who can see a very different perspective. The other one is my boss actually In any case, I consider this a victory for epistomology and I am just bragging

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791

posted Jul 30, 2006 17:12:00

0

I still need to be sold a solution based on what problem is being solved. Theory is nice to a point, but if it's simply more effective to do the "wrong" thing, most humans will.

I've been on the other side of theory arguments, trying to "sell" OO to folks who don't believe in the benefits. Sometimes we have been able to convince someone that managing dependencies and controlling what changes for what reason is worth introducing extra classes and abstractions. You might win me over on this one, too. I don't want to be Tablizer at the end of the day, so I'm still listening.

What's the worst thing that happens in the way the original poster and I write Java? A test for null? I'm not convinced that's a big problem. Unpredictable paths with unchecked exceptions? Definitely more opportunity for defects my users will care about. Mathematically unsound? I'm pretty sure I don't care. Yet.

See if I've learned anything: I believe one goal you have is to make code say what it's going to do and assure it does nothing more or less. I agree on the clear communication of intent part. It's a challenge to make sure any design adds clarity to the problem and not, as you say, ugly verbosity. To date I'm willing to sacrifice contractual guarantees for simpler communication.

manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312

posted Jul 31, 2006 03:10:00

0

Tony/Stan

Thats totally new discussion for me.

But currently I have to go with the one of the exception handling approache s in the mentioned layers in my original post.

My original question was the better of the two mentioned approaches.

Stan as you mentioned currently in case of error situations I will be informing the user with a standard service not available at the moment sort of the message. & i dont think even when the implementing technology changes to something like EJB the exception handling approach will differ.