> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > > 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.
Its a PITA any way you look at it. > 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. Yep, or at the *very least* casting it immediately in contextualize so that the container can catch that problem. > 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. And then the component fails regarding its contracts... Anyway I consider the practice a fragile contract at best. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
