Leo wrote:
> True, but here we're really going into whether RuntimeExceptions
> should be tested for and caught.
Personally, I have an extremely dim view of the lazy use of RuntimeException
instead of properly declaring exceptions in the interface. Debugging them
in client code is a PITA as it is, and in this case because we are dealing
with a dynamic assembly model, the an end user deployment may be calling a
component that the developer has never seen.
In this case, the Container is passing in a narrow type with the expectation
that the class will downcast it. Personally, I *would* recommend the
try-catch coding pattern, and doing it immediately in contextualize.
Berin Loritsch wrote:
> A *Container* needs to be able to recover from ALL exceptions
> thrown by components. This is a real practical requirement. If
> a poorly written optional component introduces a NullPointerException
> or a ClassCastException, and the container does not catch it and
> recover from it then the whole application will fail.
I agree that container (and all platform code) should be robust. But here's
a rub. There is no guarantee that the Component won't take the Context,
squirrel it away, and cast the thing later when it needs it. And when THAT
happens, who sees the ClastCastException? Quite likely some other
component, whom is not expecting those kinds of internal errors to leak out.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
