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]