I just found a great article about why it's bad to catch general exceptions, you know like:
try
{
throw new ApplicationException();
}
catch (Exception ex)
{
// Handle or swallow.
}
That this is bad I've known for a long time, actually I've been familiar with a couple of very good reasons that this is bad for a long time too. For example when catching System.Exception the exception you catch just might be an OutOfMemoryException and just how are you going to recover from that? When talking to other developers about this bad behavior it's always been difficult to find really compelling arguments though but I think I found them in this article.
Am I the only fan of the Java way, where you explicitly have to say that your method throws one or more exceptions? The .net way of doing it is relying too heavily on documentation as I see it, and relying TOO much on documentation can never be a great idea knowing how well (or actually bad) most systems are documented.
no, you're not the only one who would like to have this specific java feature in .net.
ReplyDeleteto explicitly mark methods with the possible exceptions is much clearer than just write it into the method documentation.