This may sound a bit obvious, but I'm not a fan of checked exceptions for *unrecoverable* situations either. I do, instead, firmly believe in the fail-fast principle: any situation that can't be recovered demands immediate attention, and should be looked at by the developers as soon as possible. I'm not saying that any unrecoverable exception should throw a '500 Internal Server Error' in the face of the poor user - in some cases, this would protect the application from swallowing or processing wrong data, but I'm all for logging accurate and meaningful stack traces.
peace,
-cv
-----Mensagem original-----
De: Jason Carreira [mailto:[EMAIL PROTECTED]]
Enviada em: quinta-feira, 16 de outubro de 2003 12:17
Para: [EMAIL PROTECTED]
Assunto: 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.
In general I'm not a fan of checked exceptions for unrecoverable
situations.
Jason
-----Original Message-----
From: Michal Mosiewicz [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 15, 2003 3:46 PM
To: opensymphony-webwork
Subject: [OS-webwork] XWorkException extending RuntimeException
I've noticed some code in xwork that is probably to deal with OGNL
deficiencies in terms of proper exception handling. OGNL doesn't
contract
any parsing exceptions and it seems they are added by means of
ParseException extending XWorkException that in turn extends
RuntimeException.
I don't think it's a good idea to create XWorkException as
RuntimeException
sublass, cause it may be used as common root for all XWork related
exception. And choosing RuntimeException for root is bad, cause it
doesn't
force contracting exceptions.
I think that better solution would be to make XWorkException and
ParseException non RuntimeException, and to create internal legacy
mechanisms (internal exception types) based on RuntimeExceptions to
catch
conversion problems that would be in turn properly wrapped into
ParseException.
Assuming OGNL is finally refactored with proper handling of conversion
issues this solution would be easy to reintegrate - then one would just
drop
legacy mechanisms in favour of regular exception handling. The code
"above"
OGNL would be run with no changes, however this code would already have
strong contracts for exceptional conversion situations.
Of course anyone is free to disagree, but I think that RuntimeException
(i.e. hidden exceptions are bad, as they are hard to debug sometimes).
-- Mike
-- Mike
-------------------------------------------------------
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
-------------------------------------------------------
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
