 |
Enforce your own error handling standards |
Most code analyzers use standards that are not always applicable.
devAdvantage offers configuration capabilities that make it easy to define and
enforce your organizations best practices for exception management. What’s
more, devAdvantage can help implement the standards. Using devAdvantage you can
-
Enforce the use of specific user-defined exception base classes
-
Define what exceptions can be thrown
-
Use your preferred error reporting infrastructure
-
Define what situations require error handling
|
|
|
|
Instrument your code with one click |
The Application Tracing rule allows you to quickly add or remove instrumentation
in your application. Using the .NET Framework tracing infrastructure found in
the System.Diagnostics namespace, devAdvantage can implement method tracing
using the Trace class.
-
Control where tracing is implemented through rule scoping
-
Use .NET tracing framework to leverage custom and third party trace
listeners
-
Control tracing levels at runtime with trace switches
-
Configure method trace information to include argument values
-
Remove all tracing as quickly as it was added
|
|
|
|
Lower the cost of application support |
How many times have you had an application in production raise an error that
leaves you without the information you need? The cost to support
and development as well as the impact on customer satisfaction
can be enormous. devAdvantage can help you...
-
Increase error detection capabilities
-
Provide more informative error messages
-
Implement program execution tracing
-
Improve design and use of exceptions
-
Integrate error publishing services
-
Make your software more robust
The result is a lower total cost of development and software
maintenance.
|
|
|
The C# error handling knowledge pack contains preconfigured rules based on the
.NET
Error Raising and Handling Guidelines found in
Microsoft's C# Design Guidelines for Class Library Developers,
.NET
Best Practices for Handling Exceptions found in the
.NET Framework developers guide as well as other industry best practices.
These rules are highly configurable and offer the ability to define your own
best practices.
|
Rule
|
Description
|
Automatic Correction
|
|
Handled Exceptions should be published
|
When exceptions are handled in try catch block, the
information should be published to a system log and/or to the user. This
rule detects and implements publishing based on your needs. These include
EventLog, AssertDebug, MessageBox.Show and Microsoft's Exception Management
Application Block as well as custom event publishing methods.
|
Yes
|
|
Specific call requires a try/catch block
|
Enforces the requirement that certain calls have a
try/catch block around them. This rule allows you to define under what
circumstances you should use a try/catch block. Examples include
references to certain objects, calls to certain methods or encapsulating
specific methods with centralized exception handling.
|
No
|
|
Method requires tracing implementation
|
Enforces the requirement that specific methods have
enter/leave tracing implemented. This rule makes it easy to
completely add or remove instrumentation from your solution using the
Trace class.
|
Yes
|
|
ArgumentException should be used if invalid parameters are
passed.
|
Exceptions of type System.ArgumentException should be
thrown when an invalid argument has been passed into a
method. These include:
System.ArgumentException
System.ArgumentNullException
|
Yes
|
|
Do not create methods that throw IndexOutOfRangeException
|
System.IndexOutOfRangeException is a system exception thrown
only by the runtime and should not be thrown by application code.
|
Yes
|
|
Do not create methods that throw System.Exception
|
System.Exception is a base class for subclassing all
exceptions and should therefore not be used directly.
|
Yes
|
|
Do not create methods that throw
System.NullReferenceException
|
System.NullReferenceException is a system exception thrown
only by the runtime and should not be thrown by application code.
|
Yes
|
|
Do not create methods that throw
System.Runtime.InteropServices.ExternalException
|
ExternalException is a base class for subclassing COM
Interop exceptions from and should therefore not be thrown directly.
|
Yes
|
|
Do not create methods that throw System.SystemException
|
System.SystemException is a base class for
subclassing all system exceptions and should therefore not be thrown
directly.
|
Yes
|
|
Localize strings for any exception messages
|
Localize any public facing exception strings by putting
the message strings in a resource file. This rule will automatically
localize the string, create the resource and make the call to
Resources.ResourceManager
|
Yes
|
|
Test for Null argument before referencing
|
It is good practice to test method arguments for null before
referencing, and if they are null throw an ArgumentNullException.
This can provide more detailed information in cases where an unexpected error
occurs. If this is not done the exception may be a
NullReferenceException with very little information available.
|
Yes
|
|
Re-throw should not throw with argument.
|
Do not re-throw the same exception using the exception
argument in the throw statement. A try catch block that throws with the
argument causes the loss of the original stack trace when the
Exception.StackTrace method is called.
|
Yes
|
|
Exception class names must end in the word "Exception"
|
Exception classes, those that inherit either directly or
indirectly from System.Exception, should be suffixed with the word
"Exception". This rule understands common misspellings and other suffixes
such as "Error", "Warning", etc.
|
Yes
|
|
Exception classes Must Be Marked Serializable
|
In order to work properly in all scenarios, user-defined
exceptions must be serializable and have the System.Serializable attribute.
|
Yes
|
|
Should not inherit directly from System.Exception
|
System.Exception is a base class for
subclassing all exceptions in the .NET framework
and should not be inherited from directly to create user-defined
exceptions.
|
Yes
|
|
Should not inherit indirectly from System.SystemException
|
System.SystemException is a base class for
subclassing all system exceptions in the .NET framework
and should not be inherited from directly to create user-defined
exceptions.
|
Yes
|
|
Use the three common constructors when creating Exception
classes
|
It is a good practice when creating user-defined exception classes to
implement the three common constructors.
|
Yes
|