You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2007/11/24 12:59:03 UTC
[management] Why inherit ManagementException...?
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
so i'm tempted to eliminate this class and push the implementations
down into each subclass.
opinions?
explainations?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] Why inherit ManagementException...?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Nov 24, 2007 7:37 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Nov 24, 2007 8:25 PM, Robert Burrell Donkin
<snip>
> > 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 :-))
true
> seriously, I am very ok with removing ManagementException. It is
> unused and not needed anymore.
great
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] Why inherit ManagementException...?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Nov 24, 2007 8:25 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Nov 24, 2007 5:34 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
> > On Nov 24, 2007 12:59 PM, Robert Burrell Donkin
> > <ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] Why inherit ManagementException...?
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Nov 24, 2007 5:34 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Nov 24, 2007 12:59 PM, Robert Burrell Donkin
> <ro...@gmail.com> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [management] Why inherit ManagementException...?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Nov 24, 2007 12:59 PM, Robert Burrell Donkin
<ro...@gmail.com> 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.
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.
but neither ManagementException, nor UserManagementException occur in
a catch block declaration, so it is questionable if this was the right
choice.
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?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org