I have been looking into the whole issue of Exceptions and have several questions about how to choose and design Exceptions for a Seam application. There's quite a few questions below, but hopefully somebody could address them. (I imagine all these dumb beginner questions must be getting irritating by now, but I've really appreciated all your help!) 1) Should exceptions be checked or unchecked in Seam? I'm gonna guess that all should be unchecked because isn't that the whole reason that exceptions.xml and exception annotations exist...they handle cases where the exception propagates far enough up that the rules take effect. If you declared any exception as checked, you'd have to catch it and it would never propagate and exceptions.xml wouldn't be used, right? 2) Would exceptions.xml rules also not be used for any exception that was unchecked but that you caught in every case where it possibly could be thrown? 3) Would you expect to see more checked or unchecked user-defined exceptions in a Seam application? (Or does it totally depend upon the nature of the application, meaning there aren't universal best practices on this issue?) 4) I can't tell whether my exceptions should cause a rollback or not. What criteria might help me understand this decision more clearly? For example, should an exception in a method that makes NO updates/additions/removals to the database never cause a rollback? What about for ones that do make changes - is it ALWAYS yes for rollbacks in this case? 5) In exceptions.xml, is there a way to return a logical outcome name for a given exception (that would be defined in the navigation rules) rather than an actual view ID for a physical page? I didn't see an attribute for render and redirect that implies this case in the DTD. 6) If there were an exception and I needed to return a page indicating an error to the user, I could do one of two things: annotate the exception with an error code, then in web.xml (or wherever it is) define a custom view to be associated with that error code; OR I could simply do a @Render or @Redirect to the same view. So then what's the difference between returning an error code and a regular view ID? In either case, what the user would see on his screen would be the same in either case, so what criteria go into choosing one over the other? 7) An example that's got me stumped is a login() action method on a session bean. It searches for the entered login name in the database. If the login name doesn't exist, it throws a user-defined exception. I realize the questions below are application-specific, but I don't even know how to go about making these choices. Perhaps you could explain what you might do in this case and why? A) Should this be a system or application exception? B) If application, should it be checked or unchecked with @ApplicationException annotation? C) If application, should it be cause a rollback or not? D) In either case, should I let it propagate or catch it? -Wow, so confused on this! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995221#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...