Guidelines to exception handling. Two excellent links.

MSDN Best Practices on Exception Handling

Clear guidelines and rules: should be followed when making Exception classes.

[(VB.NET focus)]

Some tips on using exceptions

Exceptions are cool, but it's all too easy to overuse them—at the cost of performance. Here are three tips on using exceptions, but they all come down to variations on the rule that exceptions are supposed to be exceptional. In other words, remember that exception handling isn't supposed to replace testing for the obvious. You don't, for example, use exceptions to test for EOF conditions. Similarly:

• Don't micromanage exceptions by wrapping every possible statement in a Try-Catch block. It's usually better to wrap the whole action in a single Try statement than to have multiple Try statements.
• Don't squelch exceptions by writing code like this without a very good reason:

Catch e as Exception

• This is the equivalent of blindly using On Error Resume Next in older VB code and is bad for the same reasons. If an exception happens, either handle it or propagate it.

Which leads to the final rule—what we like to call "the good fellowship rule" for exceptions:

• If you don't handle an exceptional condition completely and need to rethrow an exception to the calling code, add enough information (or create a new exception class) so that the code you're communicating with knows exactly what happened and what you did to (try to) fix it.

[Source: Visual Basic Developer June 2001]

Often the .NET Common Language Runtime, or CLR, is directly compared to the Java Virtual Machine. Initially, there are many clear parallels: both are “managed” environments that provide a component container, both consume a “partially chewed” intermediate language, both provide low-level services like garbage collection and threading conveniences.

[Scott Hanselman]

Sun promotes a marketing program called 100% Pure Java, which is certainly appropriate if code portability and underlying operating system transparency is a desirable endpoint.

The Java VM is truly a “virtual machine” that’s ultimate goal is to abstract (virtualize) away the underlying Operating System and provide an idealized (not necessarily ideal, but idealized) environment for development.

The .NET Common Language Runtime is named well as it is used more as a Language Runtime than a Virtual Machine. While it successfully abstracts away aspects of underlying hardware through its use of an Intermediate Language, when the CLR is combined with the .NET Framework Library of APIs it is married to the underlying platform, which is Windows. The CLR provides all the facilities of the Windows Platform to any .NET-enabled Language.

If Microsoft were to truly virtualize the machine, they would have marginalized their investment in the Windows platform. The .NET Framework Library itself isn’t “pure .NET” as it takes every opportunity to take full advantage of the underlying platform primitives.

Scott Hanselman list of utilities

Chris Sells List of utilities (includes Genghis)