So very very wrong. The article suggests THROWING an application exception, not inheriting as the title suggests. And as an application exception should crash the program (i.e., no catch should be attempted as the application cannot carry on in a safe manner), throwing them in improper circumstances can be harmful.

Rule of thumb for exceptions:
Throw exceptions only when your code has encountered an error and cannot continue.
If an exception exists that applies, throw it (i.e., ArgumentNullException, InvalidOperationException)
If one doesn't, create a custom exception that extends from System.Extension.
If there is no possibility for recovering from your error (and you know this to a certainty) throw an application exception.

Rule of thumb for catching exceptions:
The lower you are in the call stack, the less likely you will be able to handle an exception.
If you can't handle it, don't catch it.
If you need to add context to an exception thrown by an internal-to-your-class routine, you should: catch, wrap in a new exception and throw that.
It is better to crash your application than catch System.Exception. That's right, slacker.

mcgurk said it all, and very well said might I add.

mcgurk, what your saying sounds logical, but since its not in a blog, there is no way it can be true.

:)