I have noticed that a number of people like to say that their scripts "don't work." I have news for you: every computer program works! It's the nature of programming: scripts do what you tell them to do. Now, you could tell them to do something wrong and get an error, but the script is still working -- just not as you hoped!

Whenever you find that a script does not behave as expected, please, please, please (repeat x10^6) don't write that your program "doesn't work!"

So, what should you say? There are reasons that cause many to say that a program doesn't work:

1) There is an error.
2) There is a bug (i.e. an error isn't being thrown, but the program is doing something it ought not)
3) There is a feature you think is a bug (very common, believe it or not).

In school they'll give you fancier names for those errors, namely:

1) Errors are either compilation errors (for compiled languages) or run-time errors. These actually display a message (or write it to a log file).

2 & 3) Bugs or features thought of as bugs are generally logic errors.

My arch nemesis MicroSoft has a writeup you may appreciate about these types of errors: Know Your Bugs: Three Kinds of Programming Errors

I encourage everyone to stick to the same principles any investigation should. You should provide the following information, if available:

1) Who. That is, who is the one experiencing the error? An admin, a customer, an affiliate, the programmer? This is probably the least important issue to answer, but may be helpful in certain circumstances.

An example is the answer of "AOL user". I simply cannot tell you how many people have trouble with AOL for 2 reasons: 1) just being plain dumb (why else pay so much for hosting?), or 2) AOL screws with things in non-standard ways. AOL users are, generally speaking, some of the most annoying b/c they oftentimes figure that being on AOL means the whole world should work around AOL's crap. (AOL and MicroSoft must share some programmers in common? lol.)

You may also want to elaborate on the "who you are" aspect so that answers don't go too quickly over your head.

2) Where. This is multifaceted: "Where" can be a URL; a portion of a program; the server, operating system, and/or browser the code is running on; ... Location can be very, very important. When I provide website assistance the #1 thing people don't tell me is the URL they were at when an error occurred and I invariably need it (when the code is not otherwise available).

3) What. This should be answered in 4 ways: What is the code you're working on; what were you doing; what did you want to happen; and what actually happened.

4) When. Time can be relevant. Take for instance the case where you're writing a server application and the application is sending out emails 2 hours later than it ought. Including that bit of time will allow help (i.e. that the server is 2 hours later than you are).

5) Why. Your ideas as to what is going wrong can be immensely helpful. There are 2 reasons for this: 1) It can expose any erroneous thinking, and 2) it can suggest thought processes that others who will provide assistance may not have come across yet. Also, answering why you think the issue at hand is a bug can help to understand your intended functionality.

6) How. How can the error be generated (step-by-step)? How do you know it's a problem?
If I can't generate the error, then you can be assured that I cannot assist in its resolution.

It's useful to remember a rule about requesting support: Too much information is virtually impossible; while a single missing fact may prevent your problem from being resolved.

I hope this helps those of you who are learning how to ask for help to be more effective requesters so that you may get higher quality, timely, and accurate assistance.

__________________
Jeremy Miller
Content Farmer - Optimized Automated Blog Posting

---

isn't this suppose to be a run-time error as well..?

__________________

---

No. Let me give an example. I once helped someone on a forum who had a problem similar to this:

[paraphrase]
I am trying to allow someone to log in only if their username and password are valid. Here's' my code:

[/paraphrase]


Now, that code is functional. It does not throw errors at run-time. It does contain a logical error. They inadvertently included the ! in the conditional expression reversing the order of results. The proper code would be

[/paraphrase]

"Proper" being defined as following the logic dictated by the system owner.

__________________
Jeremy Miller
Content Farmer - Optimized Automated Blog Posting

---

Quote of the day brought up a quote that I think is relevant to this:

"Just because something doesn't do what you planned it to do doesn't mean it's useless." - Thomas A. Edison

__________________

---