Jerry Jalenak wrote:
<confused-look-on-face>
Erik -
How then do you return a simple status from your business model to your action? There is not an 'exceptional condition' - simply a return value that the action can use to select the appropriate forward (for instance). As I've been looking into using exceptions to handle this, it appears that I've swapped a series of if-then-else constructs for a series of try-catch-catch blocks. So let me re-phrase my question - when a business model needs to return a status (not an exceptional condition (i.e. SQLException)), what is the 'best practice' for doing this?
</confused-look-on-face>
Ah, I think I understand the problem. The suggestions to use exceptions came as a result of this question:
Just curious - how do most of you return errors from your business model? Do you simply return an integer value (-1, 0. 99?) and then interpret it in the action? Or do you return a error string that maps to something in ApplicationResources? Any other techniques? I'm trying to find a 'best practice' on how to do this....
I (and probably the others who responded) thought you were asking for ways for the business/domain model to indicate to the controller/Struts layer what kind of error it [the domain layer] has encountered. This is when I suggested using exceptions, instead of returning any kind of error code whatsoever. The reason why Java has exceptions is because the problem with returning error codes is that, usually this results in a big chunk of code that tests this return code, such as a sequence of if/else statements, or a big switch statement. This is fine in C, which doesn't have Java's try/catch/finally exceptions, because you *need* to make sure that the data returned from an operation is sane.
However, with try/catch/finally, you can just put your code into a try block and catch any exceptions that get thrown in the process of trying to execute that code. So instead of testing the return code from an operation for sanity, the language lets you interrupt the operation altogether when there is a problem, and your exception handler can step in to clean up, log the error into a logfile, and set things straight. My last post, which was intended to clarify my position, basically reiterates the fact that this is for exceptional circumstances only -- not a good way to control the flow of logic in your application.
In answer to your more recent question above, "when a business model needs to return a status (not an exceptional condition (i.e. SQLException)), what is the 'best practice' for doing this?"
I don't really find myself needing to test the status of an operation. Usually an operation either returns the result I'm looking for, or it fails altogether (and goes to a catch block). I just use the value that the operation gave me, such as echoing it out to the user or performing a calculation with the result. However, I can understand that there are plenty of times when an operation can return a variety of different results, and you want to do something different with each one. That sounds like what you've described in this most recent email.
What you're asking about is an "enumeration". There's a number of different ways to implement an enumeration -- some people say just return a different String, and then you can analyze the String in your code to decide what to do with it. Others suggest using integer status codes, which is the sort of thing you'd expect in a C program (where the concept of an enumeration is supported by a language keyword). I guess Java 1.5 is supposed to feature some sort of enum support as well, though I don't know much about it.
My favorite implementation of an enumeration is Josh Bloch's "Type-Safe Enum" design pattern. You can look it up on the web, and I'm sure you'll find a few web sites discussing how to do it, and its merits. Basically you create a class that describes a "StatusCode" or something, and create a public static instance of the class _as_a_member_of_that_class_ for each possible type of that class (each enumeration). Then you can just refer to these instances, which gives you the benefit of type-safety and object identity (which you can't get with integer- or string-based enumerations). I use this all the time. What I like best about it is that you can give the enumeration behavior, by adding a method and implementing that method for each different instance, so that your StatusCode enumerations can actually *do* things! It's pretty cool.
The drawback of type-safe enum is that it can be a lot of extra typing compared with using integers or strings. Also, while object identity (==) is an easy and useful way to test the enumeration's value (to decide what to do next), this can be problematic with distributed applications or applications that use multiple classloaders, so be careful. It's extra typing, but if you implement equals() properly in the type-safe enum, you can just use .equals() instead of == and it shouldn't matter whether you're using a distributed application or not -- the type-safe enum will work just fine.
Good luck,
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
