Community
Participate
Working Groups
Looking at the SystemHostPool implementation, it turns out that none of the ISystemHostPool methods can actually throw exceptions, although they are declared to do so. API and implementation should be reviewed what is intended behavior, and under what circumstances the exceptions are expected to be thrown. API docs should be updated accordingly, and "throws" clauses in the interfaces removed if it turns out that we do not really want exceptions to be thrown.
At the same time, this code in SystemHostPool line 108 should also be reviewed: try { //FIXME Class Javadocs say that SystemHostPool is not persisted, //so this should be removed! Or should we get the pool contents by //restoring the profile instead? pool.restore(); // restore connections } catch (Exception exc) { } Apart from not really doing anything in restore(), catching away all exceptions in a method that is declared to throw exceptions seems not the right thing.
I think throwing "Exception" is weak engineering. If we throw anything it should be something RSEException or SystemException that either translates or wraps the reason - perhaps as an IStatus. If we can't really throw anything these exceptions should be removed from the signatures. My guess is that they were there when SystemHostPool was implemented with EMF.
Removed Exception throwing from ISystemHostPool. Propagated changes to SystemHostPool and SystemRegistry where necessary. Fixed the restore() method as outlined by Martin. SystemRegistry should probably be revamped to throw something other than Exception.
