See below: > -----Original Message----- > From: Michal Mosiewicz [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 2:12 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] XWorkException extending RuntimeException > > > > ----- Original Message ----- > From: "Jason Carreira" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, October 16, 2003 5:16 PM > Subject: RE: [OS-webwork] XWorkException extending RuntimeException > > > > The point of this is that where the exceptions are > generated and where > > we would want to handle them is so far apart that we'd end > up adding > > "throws XWorkException" to EVERYTHING and it would be pretty > > meaningless. > > That's not exactly my point. My point is that XWorkException > from the main XWork package seems to be likely taken as a > common root for all XWork exceptions. It's simply wrong to > assume that all XWork's exceptional situations that my appear > would be handled behinde scenes. > > I've once pointed that it's a common for XWork/Webwork that > RuntimeExceptions are abused. RuntimeExceptions are a great > deal of problems with debugging software. I experienced that > problems. The first problems I discovered with XWork/Webwork > was related to things going behind the scenes. Also - it was > related to the fact that XWork's softens programming > contracts by adding "throws Exception" to everything. I > experienced things that where hard to debug becouse sometimes > XW even ate exceptions ( there are empty > catch(OgnlException){} blocks). >
This is an unfortunate legacy of WebWork's past... I personally wish WebWork didn't declare "throws Exception". It's slightly better than a library specific checked exception, which would tie every class to WebWork, IMHO, but not as good as requiring them to be RuntimeExceptions (again, IMHO). But, be that as it may, it is what it is, and we can't change that now :-) The problem with eating Ognl exceptions is that Ognl uses exceptions TOO OFTEN, for NON-EXCEPTIONAL behavior. Unfortunate, but there you go. > Can we agree that it's one of the most useful part of > exceptions that they are designed to make programmers aware > of all the issues they have to deal with in any specific part > of they programs. And you now what's my eclipse's the most > favourite feature is? It's that immediately after I type some > code I see what problems I have to deal with. Yes, if they are problems they can reasonably be expected to be able to handle... If it's something that only a few people will ever care to catch, then it should be a RuntimeException. > > To clarify: I of course understand that many of those > problems are not elegantly solved cause Ognl is not elegant > internally. If Ognl contracted some kind of ParseException > inside it's guts, you would rather use it instead of > developing parallel solution. Then you would just decide what > to do with OgnlExceptions at the top. > > > In general I'm not a fan of checked exceptions for unrecoverable > > situations. > > Howcome you classified TypeConversionException to be > unrecoverable situation? :-) > Because this method signature: public Object convertValue(Map context, Object o, Member member, String s, Object value, Class toType) Is from ognl.TypeConverter, so I can't add checked exceptions. > Regards, > > -- Mike Jason ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
