Peter Donald wrote: > > At 10:11 10/4/01 +0200, Leo Simons wrote: > >proposal: > >For 4.0 of the framework code, CascadingException > >is updated to extend RuntimeException, > > -1 > > Whats wrong with CascadingRuntimeException???
True that. My previous +1 was for the concept. +1 CascadingRuntimeException for lifecycle exceptions. > >and new exceptions > >are created for all lifecycle methods except run(), stop() > >and dispose(). > > -1 for run > +1 for stop/start/resume/suspend/etc > +/-0 for dispose() (it will be ignored anyway) I agree. -1 for run (We can't change Runnable's interface). +1 for stop/start/resume/suspend -1 for dispose (What would that accomplish? dispose is used to clean up a Component so that the GarbageCollector will get rid of it) > >So: > >contextualize() throws ContextualizationException > > How about ContextException? It depends on it's use. If the ContextException comes from a Context.get() call and passed up out of the method, then +1 for ContextException. If it is derived only from the contextualize() method, then we should use ContextualizationException. I vote for ContextException +1. Use it to propogate exceptions from the Context object. > >init() throws InitializationException > > how about initialize() throws InitializationException ? ;) :) I know you proposed this before. Our previous decision was to keep it init() because of the familiarity of it. However, looking at the grammatical patterns of Avalon, it would be more consistent to use initialize(). You have my +1 for initialize() if for no other reason than consistency of the API. (NOTE: a grammatical pattern in a programming language is more analagous to a language idiom). > >For: > >- making use of RuntimeException means that existing code > > will be able to compile and run if the exceptions are > > not actually thrown. > > Short term benefit is not worth the long term negative effects IMO What constitutes a RuntimeException in your mind? For things that MUST succeed or fail hard, we need explicit exceptions. That would include Contextualizable, Disposable, Initializable, Composer (Composable?). For things that have more runtime meaning, we should use Runtime Exceptions. That would include Runnable, Stoppable, Suspendable, Resumable. BTW, I propose that we merge Suspendable and Resumable. It doesn't make sence to have one without the other. All that means is that the interfaces do not declare explicit classes, but may throw Runtime Exceptions. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
