We’ve all been there. We’ve found a really interesting article, page or website, you click to view it and oops…. 500 Internal Server Error. I’m sure you will have seen this beautifully crafted grey page with bright red emboldened text on it, but what does this error mean and how can we ensure that sites are built to avoid as much downtime as possible?
First off, a Server Error could happen as of a result of any code on that page that stopped or crashed unexpectedly. So really, what you’re seeing is actually an error in the code when you loaded the page, or code that should work, but was not future proofed.
Future proofing your web app can range from being as simple re-reading your code and thinking about all the possible places at which it could fail, through to running advanced tests of every line of code you wrote while looking for bottlenecks.
Spending time on future proofing is always worthwhile, but how can we ensure code is written with the future in mind? Here are my some ways you can make a start.
As in most cases of, well, anything, prevention is always better than the cure. If you can write and future proof your code in the first place, you’ll be less likely to find yourself sobbing later over a mug of tea, trying to work out how your beautiful creation came crashing down.
Programming in pairs, peer reviewing code and testing it before it’s pushed to the live server can go some way towards preventing errors. Take a moment to step back and think about any possible ways in which the code you just wrote could fail.
And I mean nothing! If there is a text or checkbox that you expect to be filled in, don’t rely on the fact that your users will know this as well. At what point should your application stop a user if they missed something on a form? If there is a field which you expect your users to fill in but isn’t set as required, you can safely assume that someone won’t fill it in…and then what?
Never assume that your users know your application as well as you. If there is even a slight chance that a user could miss a required field then you can be sure that somebody will. Make these fields mandatory and save yourself the trouble later!
Take a walk through your entire code. Double and triple check that there is no part of a statement that could crash your page. If some part of your code may not behave as you would ordinarily expect it, ask yourself what steps you can take to make it more reliable.
Next, ‘hammer’ your code. Hit it with things it shouldn’t be dealing with. If it’s a textbox expecting numbers only, what does it do if you feed it text? This will help you be ready for the unexpected.
But wait, haven’t we already covered this? No…Take this example.
You have a blog on your website, with an ID number in the URL to get the blog from the database. While not being terribly secure, what would happen if the user changed this number in the URL to get to a different blog post - to a blog that didn’t exist? The application isn’t going to know that that blog doesn’t exist, so it will carry on and return nothing. Why would you want to try and display a blog post if it doesn’t exist? More than that, would trying to show something that doesn’t exist break your site?
A simple test in the code can be added to make sure data for the page exists before attempting to show it. The tests that make sure data exists before it is worked with are invaluable and will make for fewer broken pages on your site.
There will inevitably be a time where you write some code which relies on an external web service or another page. A common example of this is websites that use Google Maps. This can result in difficulties - even if your code is OK, what if the web service isn’t?
For problems like this or any other logic which has a chance of throwing up errors, using try, catch, throw and finally statements in your code can prove useful.
Try – Write the code that you know may cause you errors.
Catch – Catch any errors that may result from the code inside your try statement.
Throw – Handle the errors properly, as opposed to letting it return a server error. Degrade the application to a custom error page instead, or run code to send an email to the developers telling them what went wrong.
Finally – Close anything that may have been opened at the time of the crash. You may have open connections to a database or items in your code that are not properly closed or built. Safely bring the application to a stop here.
The key to future proofing code is definitely prevention of problems in the first place. Pair programming is particularly effective, with one developer programming and the second reviewing the code as you always have a fresh set of eyes to catch any potential errors.
Failing that, safely encapsulate risky bits of code in try and catch blocks, then safely degrade the application if an error does occur. Everything should always be tested, both inside and outside the code. If you do this, your web application will be better prepared to handle whatever the future throws at it.
Flickr Creative Commons Image: Stephen Dann
