Hi Guys, I'm going to chime in in support of Ruimo Uno here. We have had problems with this too.
This is not a design issue. At the end of the day, the view is calling a method and what that method does is largely irrelevant. It may throw an exception, even if you have carefully designed your application to make that unlikely. I agree that you do not want exception handling code in your views, but that isn't what we are talking about here. If a unexpected problem occurs that prevents the view from rendering properly, I don't want it handled, I want an exception thrown, eventually resulting in a 500 error. The problem is that the exception IS handled (by swallowing it). IMNSHO reacting to an exception by quietly failing to render a part of the view, and continuing on, is simply broken. cheers Perryn -----Original Message----- From: Ruimo Uno [mailto:[EMAIL PROTECTED] Sent: Monday, 20 August 2007 1:57 PM To: Struts Developers List Subject: Re: Exception thrown in OGNL evaluation. Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
