JMHO, but I think it depends on the case. In your product example, I'd let the page itself handle the error since it's relatively clear the user tried to access a non-existent (possibly removed or non-authorized) product. For a completely random, non-existent url, I'd try to handle it as soon as possible with a generic 404 page. Throwing exceptions is expensive, especially on open web there will be crawlers and bots hitting your server all the time (I've seen a case where a security scanner crashed an app because of its poor exception/ non-existent page handling).
Kalle On Thu, Aug 28, 2008 at 4:36 AM, Geoff Callender < [EMAIL PROTECTED]> wrote: > Thanks, Howard. > > Surely someone has an opinion on which approach is best?!?! Suggestions, > please. > > Geoff > > > On 27/08/2008, at 9:18 AM, Howard Lewis Ship wrote: > > Don't forget about the "exception" event that allows a page to handle >> its own exceptions before they are passed off to the >> RequestExceptionHandler service. >> >> On Tue, Aug 26, 2008 at 3:12 PM, Geoff Callender >> <[EMAIL PROTECTED]> wrote: >> >>> I'm looking for thoughts on the best way to handle this situation that >>> almost every page has to deal with. >>> >>> Let's say the user chose http://myhost/myapp/products/123, so the >>> Products >>> page tries to get product 123 in onActivate. What if the product doesn't >>> exist, or the user is not authorised to view the product? I see 3 >>> options: >>> >>> 1. Handle it on the same page - either display the product or display the >>> error, on the same page. >>> 2. Return a new page, possibly setting it up with a message. >>> 3. Throw an exception and interpret it in your app's exception page. The >>> exception page could give certain exceptions special treatment eg. >>> DoesNotExistException and NotAuthorisedException might get different >>> treatment to unexpected exceptions. >>> >>> Approach 1 has the big advantage that it keeps the same URL - the user >>> can >>> see what they requested. >>> Approach 2 gives you complete control over the page they see but the user >>> can no longer see the URL they requested. >>> Approach 3 is really simple to implement. >>> >>> Are there other considerations? Is one of these more RESTful? >>> >>> Cheers, >>> Geoff >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
