I'm sure that an exception handler mechanism for XWork is not necessary, but an advantage that could satisfy a part of the WW community is not bad. I can understand all of your points of view, but when a framework proposes an optional valuable feature, it's obviously good to promote the framework. Moreover, Struts has this functionality, but I could accept it's not my best argument ;-)
Richard HALLIER Chef de projet [EMAIL PROTECTED] 01.40.12.41.52 www.uniclick.org UNICLICK -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Jason Carreira Envoye : lundi 3 novembre 2003 01:12 A : [EMAIL PROTECTED] Objet : RE: [OS-webwork] Exception handler proposal I wish we could change the "throws Exception" but it's been there since before WW 1.0 and we decided early on to carry it forward to XW to allow a better path forward... > -----Original Message----- > From: Michal Mosiewicz [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 02, 2003 5:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Exception handler proposal > > > >[...] > > 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 > ------------------------------------------------------- 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 ------------------------------------------------------- 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
