Modern programming languages have built-in support for handling exceptions. When an exception is raised, the system can wind the stack back to the exception handler, run the exception handling code, and continue as if the exception hadn't occurred. This means that your methods don't have to always pass back error codes and don't have to check error codes to make sure the operation below them worked. The problem with exceptions is that they break the normal assumptions you have about how code works. You normally assume that a method only returns at certain times such as when you expicitly tell it to return or the method finishes. An exception, however, can cause a method to be partially run. Nothing warns you in reading the method that one particular method call will raise and exception and the method you're reading won't finish.
I prefer, therefore, to only use exceptions for exceptional things. If something really isn't supposed to happen but it does, handle it with an exception. For things that you expect might happen, you shouldn't be raising an exception. For example, it's fine to raise an exception when a socket connection was unexpectedly terminated, but don't use exceptions to signal that the user entered 13 as the month number in a date.
Download