In the course of execution your program may encounter a variety of errors, caused by any number of things. These errors can be generally divided into three classes. The first class is the not so bad class, and includes errors that can be easily predicted and corrected once detected. For example, a user enters an alphabetic string when they were asked for a number. This can be checked for, and if the wrong input is given, more input can be requested to correct the problem.
The second class of errors are those errors that can be detected, but not corrected, and thus require the immediate aborting of the current 'action' or even of the entire program. The fact that they can be detected, and more importantly predicted, in the sense we know there is a likelihood of a particular error occurring, means we can write programs that recover from these errors with reasonable grace. An example of such an error might be requesting the name of a file to be read from disk, checking the file exists before opening it, opening the file ... at this point we have passed a point of no return, we can no longer 'correct' any errors relating to this file ... and reading. But the file is incomplete! We expect to read in some sequence data, but only the title line in the FastA file is there. Because we can predict that such a situation might occur, we can write our program to recover from the error, by clearing any data it did read, and printing a message that the file was not valid, and returning the user to the point they were at just prior to choosing that particular file.
The down right uglies of the error world are known as the fatal errors So named because they are fatal to our programs causing them to terminate immediately, not even giving the user a chance to save or otherwise correct the situation. Fatal errors are normally caused by hardware 'faults', like trying to read from a flash disk, and the user pulls it out mid read. But most often, fatal errors indicate bugs in our programs. Many fatal errors can be downgraded to 'not so bad' or 'bad' errors quite easily. For example, attempting to index a list beyond its range is a fatal error, but a simple check to see if the value used as the index is within the range of the list makes this a 'not so bad' error.
The general way to handle errors is to alert the user, usually by a printed message or pop-up window, and either give them the opportunity to correct the conditions that caused the error, or return them to the point they were at prior to causing those conditions. But what message should we tell them... Well, let's first look at bad error messages!
We can look at the top four and laugh. But we can also learn. The reason these are bad error messages is that they do not tell anyone (in a layman understandable way) what has gone wrong. The fifth would normally be a very good error message, except if it's wrong, for example if there were no ';' on line 43. This happens more regularly than you might think, usually because output of the error message has been delayed and the original cause of the error lost in mists of time.
We have to understand that error messages are produced for different reasons, and for different people. Error messages that are technical and verbose often help us debug our own code whilst we are writing it, but for those error messages the user is likely to see (file does not exist, invalid input, etc...) we are writing for a different audience. So when writing error messages (and you should be writing them a lot) remember