 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / August 2005RMI Boundary, Package Visibility, and Exception Propagation
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 > One widespread practice is to make sure that all the exceptions in the > server derive from one DomainException, that way you can define all [quoted text clipped - 5 lines] > will sometimes want to disambiguate between various subtypes of your > DomainException such as in the case when the database is down. I think there is almost always a need to distinguish between exceptions which indicate that the call can't even start (e.g. bad config, database is down, ...), exceptions which indicate that the call failed but could be retried (temporary resource shortage or overload), and exceptions which indicate that the call failed due to a semantic (business rule) error at the server, as well as RemoteExceptions which should be entirely separate again (and it is a pity that they weren't better structured along these same lines). > That > brings us to the question: should all the server side exception be > contained in a client accessible package? If you mean putting them all into a single Java package, I don't see the connection, and I don't see any reason to do it. General Java practice is to put exceptions into the packages that throw them, and this works well enough for most people. EJ What I mean is that the RMI client (say a struts based app) is going to need a jar in its path from which to import the exceptions. Now say some DeepInternalServerException is thrown and the client needs to differentiate it from some other exception, would the client have to install a jar in its path that contains the whole deepinternalserver package? I know space is not a limitation these days but for aesthetic reasons I think it would be nice to have the jar that the client needs only include the serializable classes and remote stubs not the whole server app. This separation works well until you hit exceptions and then you need to install your whole server jar in your struts path. Thanks for the first answer by the way. It's a very useful distinction. - Robert Well all the client needs are the exception classes, not the whole megillah, and you should certainly never deploy server code to the client. RMI systems generally need a JAR that are common to the server and the client, certainly including all remote interfaces and exception classes. There is no need for this JAR to be restricted to a single package, it's only a mechanical question of how you build the JAR. E.J. Thank you so much. Last very short question. Could you confirm that you would see it roughly as follows: Say you have the classes for your server app in two packages: "com.mycompany.internalserver" and "com.mycompany.deepinternalserver" There is a third package of RMI api facades "com.mycompany.api" which includes all the remote interfaces, serializable value objects, etc - basically, stuff that client needs to talk to the server. So then the server.jar will include all three packages whereas the client.jar will only include "com.mycompany.api" and then just the exceptions (not whole packages) from "com.mycompany.internalserver" and "com.mycompany.deepinternalserver". So the client will still import classes from packages with internalnames but they will only include exception classes not all classes from the internal server packages. I guess I would rephrase as follows: is it a good idea from the "best practices" perspective to put all the exceptions that are shared into some "com.mycompany.sharedexceptions" package or is it ok for the client to reference then from the internal packages. Thank you again! - Robert > E.J. > [quoted text clipped - 20 lines] > some "com.mycompany.sharedexceptions" package or is it ok for the > client to reference then from the internal packages. I've already answerered that, haven't I? (a) I would have three JAR files: server, client, and common. (b) I wouldn't have a strong association between JAR files and packages, I'd tell my build.xml or IDE what classes go into which JARs (i.e. not just by package). (c) I wouldn't normally put exceptions anywhere except in the packages that throw them. It's up to you though, there are arguments both ways. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.