- A 'common' connection, but not connected to Earth.
- A connection to the power supply (usually to the negative terminal)
- A connection to the inside of a shielded metal box
- A connection to a metal stake driven into the earth (or a connection to a metal water pipe which extends out of the house into dirt.)
- A computer, much like a personal computer only with more power
- A special purpose hardware component, more powerful than a PC, but limited in other ways such as a blade server
- A software component that 'serves' one or more clients
- A special purpose device such as a DNS Server or FTP server
Without electrical grounding our electrical systems would be erratic, appearing to work for a while and then, without warning, collapsing, or providing a sudden 'notice' of buildup in the form of foot-long electrical arcs. It would be common for people to die from light-switch-induced heart fibrillations. I had the opportunity to manage USAir's network on which their System Control Center operated. If that mission critical system was ever down for four hours, the FAA would require the airline to shut down. Once a month the entire local area network would simply cease to function and the only known remedy was to pull all of the token-ring cables out of the multi-station access units (MAUs) and reinsert them - a process that took a little over three hours. After much investigation we eventually discovered that the original installers never grounded the network.
If we were to treat our applications like electrical systems, we would provide a grounding path; a way for the build up of time-outs, errors, notifications, and bottlenecks to be channelled to a point of dissipation.
Now, some will say that we do log errors, catch exceptions, and terminate threads - and that is good, but if we are treating each of the possible anomalies as separate events and addressing them each on a case by case basis, rather than providing a systemic solution, we open the opportunity to miss one. We should design our systems with a default path for all non-desired behavior, and (this is critical) we should design tests to validate the handling.
Again, let's be sure we're clear. Certainly we should log errors, we should catch database exceptions, and pooled resource exhaustion; but we should have an overall architecture in our applications that allows all of these events to be channelled so that the application itself never fails - or if it must fail, it does so in a controlled manner. Systems that are designed in this manner are well grounded. Programmers who don't do this, should be grounded as well (ouch!).