Frank Lawlor wrote: > 1) why doesn't findForward() throw an exception > rather than returning null?
Conceptually, not finding something in response to what could be a dynamic query is not an exceptional event. A SQL query returns an empty set all the time. Its up to the application to decide what to do about that. As we explore doing more with exception handling in an Action, it may be a good idea to add alternative methods that threw an exception instead of return null (but without changing the existing API). Please feel free to enter this to Bugzilla as an enhancement request. In the meantime, if you feel that it should throw an exception, then I would recommend subclassing ActionMappings and adding a method that called findForward and threw the exception of your choice if it returned null. Another way to go, would be to add a helper method to a base Action class that did the same thing. > 2) more generally, I am concerned about errors > that you cannot discover until runtime and then > only by ensuring you have tested every possible > situation. > > One of the important things about Java is the > emphasis on catching things at compile time. > It would be good in the design of Struts to keep > some focus on allowing error detection at > compile time, or at least at application init. > > In the above case for example, there may be some way to > use static constants rather than strings. It would > be good to look at some of the other Struts elements. I don't believe that there is a way to require developers to use String constants, although I known many developers do. And even if we could, the constant couldn't be imported in an XML file, where it would do the most good. I'm not saying using String contstants for fowards isn't a good idea. I do it myself. But it's not a panacea. After all, even if the constant exists, a Java compiler can't tell if it is the "right" constant. And there are plenty of other errors that a Java compiler will never ever catch. Even if you get the name of the forward right, there's no guarantee that the path associated with it is any good, and won't return a 404. > This may not seem like a big deal to some people, > but I remember well the 'bad old days' of maintaining > applications with interpreted code. Runtime discovery > of bugs is a bad characteristic for quality apps. > > "Introspect, don't interpret". I'm just afraid this is a fundamental aspect of writing Web applications that support outside components, like JavaServer Pages or Velocity templates. Introspecting whether these components exist, or whether the right one is being called, is outside the scope of a Java compiler. In order to solve other problems, all of the Struts components are put into wrappers that encapsulate implementation detail behind a logical name. This is very powerful feature that makes it possible to keep the components loosely coupled. We can change a global forward in the configuration file, and have that change reflected in a JavaServer Page and in an Action, without recompiling either one. But, at the same time, we can't guarantee that the change makes any sense, or leads to a valid path, or any number of things. And since these changes can be made without recompiler, there is no way for a compiler to even think about checking them ;-( I think in real life the only practical solution is to realize that runtime testing of Web applications is an essential part of development, and that tools like Cactus and StrutsTestCase have to as much a part of our environment as Ant and Jikes. One very cool tool is the StrutsResourceChecker http://husted.com/struts/resources/checker.html What would be very neat would be something like this that could analyze the configuration file and check all the links, like the Web site link checkers do. This could lay the groundwork for something that introspected the Action, and checked to see if the forwards went someplace. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
