On Nov 24, 2007 8:25 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007 5:34 PM, Bernd Fondermann > <[EMAIL PROTECTED]> wrote: > > On Nov 24, 2007 12:59 PM, Robert Burrell Donkin > > <[EMAIL PROTECTED]> wrote: > > > i'm trying to factor out a user-library module but i'm having problems > > > since the management interfaces throw exceptions which subclass > > > ManagementException. i don't understand why this coupling is necessary > > > > a management command can go wrong. they tend to raise for example > > DB-specific or transport-specific exceptions. > > so it would make sense to define a management specific exception to > > catch all implementation specific exceptions and wrap them, making it > > clear to developers we would not want every other exception to be > > thrown. > > fine > > > historically, the only properly supported management interface was the > > RemoteManager console. then I extracted the management funtionality > > into its own implementations and added MBeans/JMX, so RemoteManager > > and MBeans where symmetric, more or less. still feeling the pain from > > separating the UI (Remote Manager console) from the management > > function, I must have believed that it would be cool to have explicit > > exceptions for any management domain. > > i think this choice is reasonable > > > but neither ManagementException, nor UserManagementException occur in > > a catch block declaration, so it is questionable if this was the right > > choice. > > i question only whether extending a single supertype > (ManagementException) is worth couple the different management > interfaces together > > > feel free to remove all unused code. this only adds up to the stuff to > > be maintained and confuses people. > > > > > so i'm tempted to eliminate this class and push the implementations > > > down into each subclass. > > > > you want to remove the exception? fine. but what do you mean by "push > > the implementations down..." in this context? > > i've committed (1) some UML illustrating the issue a little better
I still fail to see the impl you are pushing down. the ManagementException does not incorporate any logic. anyway... > if all management exceptions inherit from a common super class then > this couples packages together. this this is useful then that's fine. > if there isn't any good reason why these exceptions (throw by > different management interfaces) should inherit from this superclass, > then i'd like to break the inheritance hierarchy and have them extend > Exception directly. this reduces coupling in the system and increases > module independence. you are only shifting the coupling from ManagementException to Exception :-)) seriously, I am very ok with removing ManagementException. It is unused and not needed anymore. Thanks for explaining, Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
