R
robertbrown1971
When trying to properly stucture package visibility in a client/server
application the question of exception propagation comes up again and
again. I was wondering if people could point me to any best practices
for this problem.
One widespread practice is to make sure that all the exceptions in the
server derive from one DomainException, that way you can define all
your RMI signatures to throw DomainException and RemoteException so
that, as your application evolves, you can introduce new exceptions
without breaking client signatures - they can always catch
DomainException and rest assured that they caught every exception you
going to throw including future ones. The problem is that the client
will sometimes want to disambiguate between various subtypes of your
DomainException such as in the case when the database is down. That
brings us to the question: should all the server side exception be
contained in a client accessible package?
Thanks,
Robert
application the question of exception propagation comes up again and
again. I was wondering if people could point me to any best practices
for this problem.
One widespread practice is to make sure that all the exceptions in the
server derive from one DomainException, that way you can define all
your RMI signatures to throw DomainException and RemoteException so
that, as your application evolves, you can introduce new exceptions
without breaking client signatures - they can always catch
DomainException and rest assured that they caught every exception you
going to throw including future ones. The problem is that the client
will sometimes want to disambiguate between various subtypes of your
DomainException such as in the case when the database is down. That
brings us to the question: should all the server side exception be
contained in a client accessible package?
Thanks,
Robert