Berin Loritsch wrote: >>From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] >> >>From: "Berin Loritsch" <[EMAIL PROTECTED]> >> >>>At this stage what can you do about it? You are getting ready to >>>remove the component. If there is information to be passed >> >>regarding >> >>>the stop()ing of something then we should return it as >>>information--not throw an exception. >>> >>>An exception is for exceptionnal occasions--Not for passing >>>information. Using it to pass information is not good, and an >>>expensive way to do it. >>> >>>Just do what you mean. >> >>Ok, then let's say I'm in the army. >>I tell my soldier to do standups for as long as I tell him. >>START! then he collapses just before starting. >> >>Is it reasonable that I only know that he failed? >> >>Who is going to heal him? >>If I don't get to know it, who does? >> >>I am responsible for *anything* that happens to him, not just >>of the fact that he didn't start. > > > That's the start() side of the equation. I'm not talking about > the start() side of the equation. > > What *practically* can you do about it if you are stop()ing a > component? How is throwing an exception here going to help > you? What can you do to recover from it?
First of all, I should know what resources the component uses. Is this against information hiding? Yes, but I see no alternative. Let's say that your component is a StorageComponent. Stop failing would mean that the thing didn't get saved. It's not a Runtime exception, since I can expect it. If I don't expect it, who else would manage it? You say you can't do anything about it... well then who does?!?!? Should I just let it pass? :-O >>>Practically speaking, what types of components do you develop that >>>implement Startable and don't involve a background thread? >> >>Check out >> >>>the Connection handling stuff in Cornerstone. Check out Monitor. >>>Practically speaking, that is. >> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/krysalis/krysalis-monarch > /src > /java/org/krysalis/swallowtail/sheets/text/NetBeansEditor.java?rev=HEAD& > cont > ent-type=text/vnd.viewcvs-markup > > > GUI components. I see. However there is nothing done there that > couldn't > be done in initialize(). Ok, then let's do everything in a a() and z(). > Avalon was never designed to be a GUI system, although it is very good > for > the background stuff. If you take a GUI out of the picture, if it is > not > an active component, why do you need start()/stop()? GUI has nothing to do with it. The fact is that init() and start() have a different meaning. init : allocate resources start : execute There are many cases (like pools, cron jobs, etc) in which you need to allocate resources before starting. And you don't stop it, it stops by itself. The JDK Thread stuff has deprecated stop, and has the thread itself stop, so it's not such a wild thing. :-P > BTW, I am of the belief that the two are tightly coupled enough to > warrant > them being in the same interface. It is better to encourage developers > to > stop() anything they have start()ed. If you haven't start()ed antyhing > to > stop(), then you are probably using the wrong interface. This kinda makes sense... But it's really freaky to call stop() on a Startable :-S -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
