• Post Reply Bookmark Topic Watch Topic
  • New Topic

Servlet Forward behaves like a break/return?

 
Dave Soto
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am attempting to create a Servlet controller that accepts all requests for a web app and forwards to an appropriate JSP.
I basically have a set of if statements that test certain request parameters, and within each if construct, I have a getServletContext().getRequestDispatcher(...).forward(...) statement.
I have been debugging my application, and it seems that the if statement will sometimes evaluate as true, the forward statement will execute, and still the debugger will continue to execute the statements after the forward.
I was under the impression that the execution would not "return" from a forward. (just because that seems convenient)
1) Was I mistaken?
2) If so, what is the appropriate way to handle this?
3) Is there ever a reason to forward to a page and then purposefully resume execution afterwards?
(If this post seems like it rambles, I apologize... I've been coding for 15 hours straight on two sandwiches and no breaks... )
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dave Soto:

I was under the impression that the execution would not "return" from a forward. (just because that seems convenient)
1) Was I mistaken?
Yes, you were. There is nothing magic about a forward; it is just an ordinary method call subject to the usual method invocation semantics. You can observe this most clearly if an exception is thrown in any of the pages your forward to - your original servlet is sitting slap bang in the middle of the stack trace.
Actually, a lot of developers seem not to realise this and treat "forward" as if it were "return". By the time the forward returns, the output stream is closed, so any attempt to write to the output stream following the forward throws an exception. This is invisible to the client because the HTTP response has already been committed! In other words you may never notice the difference - except in CPU usage. I don't want to know how many web applications are out there wasting time on these exceptions.
2) If so, what is the appropriate way to handle this?
After a forward, return from the service() method straightaway.
3) Is there ever a reason to forward to a page and then purposefully resume execution afterwards?
I can imagine in theory that there might be some time-consuming cleaning up to do; to minimise response time this can be done after sending off the response. I can't think of a practical example though.
- Peter

[This message has been edited by Peter den Haan (edited September 27, 2001).]
 
Dave Soto
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you so much. It's always a creepy feeling when something strange is happening in your app, and then you step through debugging and what you see only makes it seem more strange.
Well, it turns out that the problem I was having had nothing to do with my improper usage of the forward method. (A result of the "app runs correctly but throws invisible exceptions" phenomenon you described) My problem was far simpler.
I use Together Control Center, and I kept running my app without rebuilding first. So, regardless of how I changed my code, I kept getting the same errors. I've never seen an IDE that doesn't automatically build an app before running it. I've been using TCC for three months, and I don't remember having to explicitly rebuild before, but I certainly won't ever forget to do so again.
Thanks again for your help. Your explained with perfect clarity behaviors in my code that were haunting me.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!