>[...] > Then wouldn't it be the invoker's responsibility, rather than the > framework's? I'd say that exceptions should be delegated to the most > responsible party, not the framework. Thus, the web app exception handler, > or the caller's, in the case of XWork's.
I think this is a good point. I also would like to warn that what some people try to convince for here is nothing but an attempt of creating parallel worlds inside xwork/webwork. Even if xwork is used in JSDK context it appears that JSDK's internal mechanisms are not sufficient, and effectively has to be replaced by alternative, parallel version of error handling mechanism. And the reason for it is to make a use of xwork's/webwork's mechanisms. It is definitely not good if framework has to duplicate some mechanisms. That means that framework doesn't integrate well, and you have to look why it is so. IMHO the problem comes from that XWork promotes non-careful exception handling. Becouse everything throws exception it's very tempting to leave all the handling to the caller. Finally people are left with the container receiving numerous exceptions that it is not designed to work with. It's easy to conclude with an idea of extending exception mapping mechanisms. I personally think that you should consider that good framework is the framework that only works within it's specific problem domain, and not duplicates exsisting solutions. --Mike ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
