It is a given fact that at some point in your website building process, something will go boom. This happens to novice users and seasoned web developers alike. You are doing something enormously complex, despite what you may have heard from your local high school student.
You are taking code designed by dozens of different people and mixing it together into a working website. The people who wrote this code have no idea how your server is set up, what your comfort with technology is, or which pieces of code you may have mixed together. They have done their best to allow for every possibility they could think of, but at some point… it. will. go. boom.
So what do you do when you find yourself confronted with this:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, email@example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
This helpful little notification is the equivalent of “Oh noes! Something bad has happened! Call for help!” It provides little information and even less guidance on fixing the issue. It is also worth noting that, if you have chosen to go it alone, the “server administrator” the error message is asking you to contact is you. This is usually the point at which myself or another developer will receive a phone call for help (it is also typically the worst time to call the developer, which we will talk more about later).
Most developers have had tremendous experience with stuff going boom. We experiment, tinker and fiddle the way most people breathe, and at one time or another, each and every one of us has brought a computer or server to a crashing halt, an inert mass requiring the complete re-installation of everything. We are also painfully aware that we can do it again at any time. However, beyond the initial swearing and fist shaking, we are different in the fact that this does not frighten or stop us.
Developers plan for the fact that things will go wrong. We have entire systems set up for backing things up, testing and moving between versions. If something goes boom, we can pretty much hit rewind and go back to the version that was working before while we fix the current problem. We build things in such a way that boom only stops us for a few minutes, while for most people, one good boom can lead to weeks of down time while trying to figure out the problem and sometimes it will just stop you completely out of shear frustration.
So how do you prevent this kind of frustration? Talk to a developer before the problem even starts. Next we will cover a few options for this in our series wrap up which asks the question: When To Call A Developer For Help.