Null PointerAn attempt to use a variable that hasn't been initialized. This is a very common error that programmers encounter but it is considered a poor practice to let this propagate to users or administrators as it conveys no useful information. For example, if a null pointer exception occurs because a customer's name is missing in a database an error such as "customer name not in database" is more meaningful to administrators.
Missing FilesThe system depends on some file that doesn't exist or isn't as expected. This often occurs due to "dependency hell" whereby different software packages share libraries of functionality. This means that installing or uninstalling one program can affect other programs as they may update libraries that are shared. This results from software architecture that values reuse and efficiency over stability, resilience and maintainability.
Out of MemorySoftware depends on memory and typically can't function when the operating system can't provide what it needs. In some cases, the physical machine has memory but some constraint on memory has been placed on the software by the operating system or a framework on which it runs. For example, a java program can crash if its Java Virtual Machine runs out of memory due to a configured limit.
UnauthorizedIndicates that a user or entity isn't authenticated or that they are authenticated but don't have authorization to perform a function or access a resource. For example, a bank customer without a brokerage account attached to their card who attempts to access a screen for trading stocks.
Parsing ErrorAn inability to process structured information such as a file. Old systems typically require information to conform to strict formats and will throw an error at the smallest inconsistency. For example, an XML parser that throws errors when a single bracket is unmatched. Newer systems tend to be more flexible and are often based on loosely defined information structures that are less likely to generate parsing errors.
Invalid ParameterA parameter is input that is given to a system by users, configuration or other systems. Where the system doesn't understand this input it may throw an error. This is an extremely common type of error that is known by many names such as bad arguments or unexpected format.
Unexpected ErrorIndicates an error that results from a software flaw as opposed to an error that is a feature of a system. This feels a little humorous but errors are often specifically handled by systems. For example, an ecommerce site that finds that an item placed in a cart has gone out of stock may present an error to the customer at checkout that is essentially a feature of the system.
Fatal ErrorA fatal error is an indication that a program is giving up such that it has essentially decided to crash. This often occurs because an expected resource is completely unavailable. For example, a web browser that is getting no response from the operating system may throw a fatal error.
Blue Screen of DeathA blue screen of death is a complete system crash that is handled in some primitive way by a low level system. Old fashioned systems tend to claim that they must crash for "safety" when an illegal operation occurs. This is debatable and isn't as common amongst more modern systems that are more likely to prioritize resilience over "safety."
Halt and Catch FireHalt and catch fire is an analogy to the tendency for systems to overreact to errors. For example, a memory card that completely disables itself when it detects a problem with a single segment of memory. Engineers commonly claim this is the only "safe" way to handle such errors but this may prevent users from recovering data from a device that is mostly physically functional.
GlitchAdvanced modern systems that are designed for resilience don't halt and catch fire in the name of safety. These systems are likely to have glitches whereby strange things happen due to underlying errors without any big crash. For example, a game environment where an AI suddenly does something that violates the entire physics of the game environment.
Error CodesIt is a common practice to show users an error code that differs from the underlying system error. In some cases, these are mapped somewhere such that they can be investigated when they are reported by users. In other cases, they aren't really mapped in any meaningful way such that they are simply designed to make the user feel they've been informed. For example, a bank that displays "Error R700" for almost any technical failure such that the message is essentially meaningless despite appearing to be highly specific.
HTTP Status CodesHTTP status codes are used to indicate errors on the internet in the response of a server to a client. These codes indicate both successful responses such as code 200 that means "ok." The following are examples of codes that indicate an error.
|400||Bad Request||The request from the client wasn't understood by the server|
|The client isn't authorized to access the requested resource.|
|404||Not Found||The resource wasn't found. For example, a web page that has been deleted.|
|418||I'm a teapot||Part of the official specification but this appears to be a joke. Humor is common in the culture of communicating system errors.|
|429||Too Many Requests||The server is too overloaded to respond at the moment.|
|500||Internal Server Error||Indicates an internal software error on the server. For example, the server's database is down.|