In general I find articles on InfoWorld interesting, informative, etc. but I rather disagree with "never" statements in their recent article Best practices for handling exceptions in C# . I say this based on 30 years of development in many languages, across many platforms, though the bulk on Windows. (I've been doing Windows development since Windows 3.0 when you started Windows from DOS.)

Always derive from the Exception class

I agree with this. In fact for any non-trivial application you'll want to have a hierarchy of exception classes and often an abstract base class exception that you can use to catch any application specific exception as I find that I often need different error handling for application specific exceptions that more generic ones like FileNotFoundException. What does FileNotFoundException tell you? Possibly very little depending on the message passed to the constructor. Exceptions like FileNotFoundException are usually most helpful when wrapped by another application level exception to provide context, especially if your app deals with multiple or many application level files.

Oh and it goes without saying that this is all with the assumption that exceptions are being logged for troubleshooting and support purposes, otherwise you might as well catch only at the "top" and put up an message for the end user (assuming there is one) with an "Opps!".

Handle exceptions at the highest level

Agree, but sometimes the data that's needed to understand root cause can only be captured at low levels in which case you must catch exceptions at that lower level, capture that information in an exception and (re) throw. In this case "re-throwing" is likely a wrapped exception with the data needed for troubleshooting and support.

Use predefined exceptions and clear error messages

Maybe for smallest simplest of programs - see my comments about "Handle exceptions at the highest level"

Use try/catch/finally blocks to handle exceptions

Agree, but I'd prefer freeing resources with via "using" when possible. It's simpler, cleaner, less typing, less to read, more maintainable.

Avoid throwing and re-throwing exceptions

Disagree. One shouldn't catch and rethrow without a reason, but there are good reasons to do so. See my comments about "Handle exceptions at the highest level". I really do not like the statement "It is ... good practice to avoid throwing exceptions". Yeah throwing exceptions for some form of control flow, especially in a long loop is very possibly a bad idea. More on this later.

Never swallow exceptions

I disagree. While it should be rare, "never" means "never". I've written my share of applications (you must understand that I've worked in software from embedded applications to any flavor of web applications to financial platforms, on Windows, Unix/Solaris/FreeBSD/Linux, C/C++/Java/C#/Python for 30 years) that need to deal with exceptions that are thrown by a framework or library, but the automation or problem being solved may have necessitated a design with a retry or recovery mechanism that is outside the scope of the code that might need to catch an exception. Maybe on another thread? Another process? In such as case what does one do with such an exception? Since recovery is elsewhere do you log it? Maybe in development, but maybe likely not in production as logging takes up time and space as well and if it provides no value then why do it? Occasionally the right thing to do is simply swallow the exception.

Rare maybe, but one of the few 'nevers in my book is to never have a rule that says "never".

How to avoid exceptions in C#

The article also references another InfoWorld article How to avoid exceptions in C# which I dislike even more than this article. While one should avoid throwing too many exceptions for performance reasons the whole point of exceptions, the whole reason they exist, is to make code more readable, maintainable. Developers already suffer from cognitive overload. I remember the days of C having an if/else or case statement for nearly any function call to handle errors. It can make code very difficult to understand. Now there are times that using a "Result pattern" can bring clarity to the code, but I definitely would not consider the first tool in the tool belt to reach for let alone be a best practice. If it were a best practice language designers would not have come up with exceptions! Using exceptions for errors is the best practice. Never mind that they are called "exceptions" they are not just for "exceptional conditions" they are for reporting and handling errors!

The highest cost in software is typically the cost of the developer. Anything that can be done to make their work more efficient is more likely more important that trying to make the average chunk of code more efficient. Of course there are exceptions, no pun intended, but most corporate developers are not writing the next nginx or SQL Server. Code needs to be fast enough of course, but nop more. The "Art of Computer Programming" calls premature optimization the "the root of all evil" for good reason. I've seen programmers waste gobs of project time, and project money and create reams of unreadable, unmaintainable code with such endeavors. Often this sort of mess is created by poorly read/educated 'pretend programmers' who should really be SQL admins. Different skill and mindset.

So that's it...

Too many programmers read only about programming and fail to study design, or process, or project management or the business of software (ah, which is about providing value and making money ... yeah, OK?). Don't get caught in this article trap blindly following rules. Read lots of different resources and think for yourself!