Not sure if I agree with your definition of exception or see how it conflicts. There are 2 java exception types, runtime and checked. These can be loosely translated as "unhandleable" and "handleable" (sort of)... Couldn't think of a better word right now...
Anyway, in terms of a business function you have different types of errors as well. Errors that the user needs to correct, and warnings that the user needs to be made aware of. What I've done in the past is to create exception types that mirror these cases in the business tier. Then you can have one translation utility that converts/forwards as necessary for the exception type. I have these custom exceptions extend the checked exception types. The logic in the utility that runs on the struts side basically converts the exceptions to messages that will be displayed in the html:errors area. In the case of a "bad" exception, the request is forwarded to an error page. Since the rendering is specific to struts, the same back-end can throw the same exceptions elsewhere and they would be handled as needed for the different front-end. Hope that makes sense. Regards...djsuarez -----Original Message----- From: David G. Friedman [mailto:[EMAIL PROTECTED] Sent: Sunday, October 03, 2004 10:31 PM To: Struts Users Mailing List Subject: RE: Java edit method - design pattern? (O/T) John, Could you pass an ActionMessages object as the second parameter to your method? That way, you still return your boolean but you could 'push' an ActioMessage on the ActionMessages 'stack' for display in an error JSP. If you are worried about keeping your business methods separate from Struts, you could pass an empty (but instantiated) (Jakarta commons?) collection type. Back in the invoking method, if the boolean is false, you could iterate through the collection and add those String messages (or whatever they were that you put into the collection) into ActionMessages for display in your JSP. I'm eager to see what other solutions are suggested by Struts users. I'm sure we'll see many different opinions, all quite effective. :) Regards, David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, October 03, 2004 6:51 PM To: Struts Users Mailing List Subject: Java edit method - design pattern? (O/T) I'm working on an application API to be deployed with struts, and am interested in how other developers are dealing with 'editing' methods, ie methods that answer a question with a true/false value, but if false is returned, you also want to know why. for example, a credit card application may have a method 'boolean allowCreditFor(int cashAmount)' which returns true if the amount requested is ok, but false if not. But what if you want to know why false is returned? Using an Exception seems to be a pretty good fit, but doesn't seem to me to be in keeping with its purpose (ie that an Exception should signal an abnormal outcome that couldn't be handled locally). Thanks for your thoughts, John Thompson --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
