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 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. - robert 1. http://svn.apache.org/repos/asf/james/server/sandbox/design-doodles/modules/management-packaging.png --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
