There is a lot of confusion about writing your own exception classes. I see far too much code out there that just catches "Exception" anyway, that I hate to complain about someone who has set themselves up to have different catch behaviour for "The server is probably offline" than for "you probably don't have permissions on that file you just told me to use". However those who write their own exceptions have generally derived them from ApplicationException. If you ask why, they say things like "well" and "er" and "um" a lot because there's no extra stuff in an ApplicationException compared to an Exception. It just made it possible for you to catch "ApplicationException" and know it would be one of yours and not from some framework code.

Only thing is, that didn't really work out -- some framework code throws exceptions that derive from ApplicationException. And really, catching ApplicationException is just as generic as catching Exception. What can you meaningfully decide to do when all you know is "some code I wrote is unhappy in a way that the built-in exceptions (invalid argument, access denied and so on) cannot properly express" ?

So the word is out. Don't inherit from ApplicationException. Got it.

Kate