kamagra how much to take

WebPart Exception Handling Standards

A while ago I posted a generic exception handler class that you can integrate into your project to do tracing and creating an event source for your WebParts. Although this is a good start to exception handling, it doesn’t provide standards. Standards (which I provide a more robust definition for when you look at the security policies that are presented on the main site) instead ensure maintainability of the WebPart, increase performance benchmarks of the WebPart, increase reliability of the WebPart, and generally decrease the overall amount of bugs that are present within the WebPart.

I am presenting this, because although I gave you a generic class to work with, and I want to show you how to structure exceptions in the most proper way so you can reap the benefits of really taking into consideration how your WebPart exception code should (and like I said in a previous post, I don’t know if this is entirely right) most likely be put into place within your custom WebPart code. This are just some exception handling standards that I take into mind when I am developing WebParts, and maybe might come into handy for you or your organization.

In this post I will show you how you should handle exceptions according to some pretty solid standards, which will help you in improving your quality of SharePoint software. You can call these “Exception Handling Standards For WebParts”… or something, or “Adam Being Bored On A Saturday Afternoon At A Coffee Shop”.

Anywayssss…..

1) Since exception handling is common in WebParts, it is acceptable to pass the generic letter “e” or the string “exception” within exception blocks. However it is better to decorate exceptions with a more intuitive parameter for code pass-off.
This is ok:

  1. try
  2. {
  3. }
  4. catch (Exception exception)
  5. {
  6. }

But this is better:

  1. try
  2. {
  3. }
  4. catch (Exception moreDecoratedException)
  5. {
  6. }

2) Along the same lines, when catching an exception, it is generally helpful to decorate your exception with the tag in order to provide subsequent developers with the appropriate information in order to tap into your code.

3) When catching exceptions, make sure that you can deal with the exceptions that your WebPart may throw. If you are attempting to throw exceptions that you can’t handle, it will clearly have bad implications for the WebPart. If you are attempting to throwing exceptions that you can handle, it can result in the hiding of other misc. run-time problems. It is best to attempt to let your exception bubble up the call stack.

4) If the exception being thrown can greatly affect business operations, the exception should be logged in an event source and tracing should be enabled in order for a review of the problem at a later date, as well as an audit history of possible problems that have occurred with the WebPart.

5) Never use an exception for flow control (meaning, using exceptions to code WebPart behavior that is not exceptional at all to facilitate code jumping). This is a very expensive operation to perform that will incur a performance penalty because of the object creation that is involved within your WebPart code for such a process. For example, when testing a variable for an integer, it would not make a lot of sense to use an exception handler, since this is not an “exceptional” process.

  1. int i;
  2. try
  3. {
  4. // pseudo test for integer
  5. }
  6. catch (Exception exception)
  7. {
  8. // pseudo not an integer exception
  9. }

6) Catch blocks should never be left empty as this will hide exceptions as they occur, although instances of the exception will still be caught. Meaning, when an exception does occur, the WebPart will fail, and the reason will be unknown. This is also known as “Exception Swallowing”. No production WebParts should allow this, however in development it is acceptable to leave catch blocks empty in the case the programmer “just wants to know if this works or not, and doesn’t care of the details of the exception itself”. Either way, just don’t do it IMHO.

This is bad:

  1. try
  2. {
  3. // Uh oh, I did something wrong
  4. }
  5. catch(Exception )
  6. {
  7. // But, I like doing nothing because my exception will be swallowed.
  8. }

7) Do not nest try/catches in an already declared catch block, as this is disproportional expectation handling. A base should be setup to deal with method inputs, and subsequent exception handlers should be constructed in order to deal with variant input. This allows the streamlining of code to occur much more rapidly. The most notable problem with using nested try/catches within an already declared catch block is that the inner catch block will be called, and then the recovery from the catch will prevent the outer try/catch block from subsequently occurring. As opposed to nesting, it is better to instead attempt to architect code so that there is one try/catch, with multiple catches appended.8) Avoid re-throwing and ignoring exceptions, instead let them be dealt with at a higher level on the call stack, until a calling routine in the call chain handles them. This will in essence allow them to bubble up. This generally involves using a finally block, since when an exception occurs that is re-thrown within a catch handler, the code in your WebPart following the catch block will never be executed. Since a finally block (which there can only be one) is executed regardless of exception occurrence guaranteeing that set of code will be executed, If you must re-throw an exception, don’t use the throw statement with the original exception argument so the call stack is preserved.

8) If you must re-throw an exception within a WebPart, ensure that you are doing so in order to customize an exception. But customization I mean like adding more detailed information to the exception besides the information that is already being passed from the exception. You should also re-throw an exception when you want to want to change the type of the exception.

9) If you are changing the type of the exception, use the innerException property in order to maintain the exception chain. The innerException property is important because it contains all the standard properties including, potentially, a further InnerException so any chained object exceptions can be investigated correctly.

10) A finally block does not necessarily mean that a catch block has to be present in order to reduce on exception handling code bloat.

11) When operations within your WebPart require validation, always use a label control to inform the user of it. This avoids complicating operations to the user and allows them to retry the problematic entry as many times as necessary and avoids them calling you.

12) When initializing a class that will require site contexts to be enabled, it is sometimes nicer to write an initialization method that you can structure exception handling around in order to handle general context errors. It also IMHO a little bit more elegant as far as general WebPart coding standards are concerned.

  1. private void Initialize()
  2. {
  3. try
  4. {
  5. Microsoft.SharePoint.SPWeb contextWeb = Microsoft.SharePoint.WebControls.SPControl.GetContextWeb(this.Context);
  6. this.curWebUrl = contextWeb.Url.ToLower();
  7. this.curWebId = contextWeb.ID;
  8. this.curSiteUrl = Microsoft.SharePoint.WebControls.SPControl.GetContextSite(this.Context).Url.ToLower();
  9. }
  10. catch (Exception exception)
  11. {
  12.  
  13. // put your fancy exception handling here, taking into these presented standards
  14.  
  15. }
  16. }

13) Do not throw exceptions from inside destructors because of the implications that can come from stack unwinding.

14) There are a lot of standard exceptions that are available to you within the classic .NET framework architecture. Exploit them as much as possible, since you can use ApplicationException, IndexOutOfRangeException, InvalidOperationException, NotSupportedException, ArgumentException, ArgumentNullException, and ArgumentOutOfRangeException.

15) When throwing exceptions, make sure that they have some readable information tagged onto them so other developers can solve the exception. It goes back to the what if you got hit by a bus theory. It helps others within the team in solving exceptions that otherwise you may only be aware of. Just remember to throw some metadata that will help others. Throw exceptions explicitly, and with the most information possible. This could as simple as just including the message property with the thrown exception.

16) If you are writing complete classes that are dedicated to exception handling (which you should avoid, see exception handling standard 14), ensure that the classes are decorated appropriately so co-developers are aware of the implications of the class (just a simple coding standard). Either prefix the class with an e (i.e. eMyHandler) or suffix with the word exception (myHandlerException).

17) Don’t throw exceptions, and then not tell people you are throwing exceptions when you are documenting your code. There is nothing worse then an error being logged, then returning to the code documentation, and then absolutely nothing in the code documentation being written about the exception.

I am interested in expanding this list of standards, and making a complete standards document that integrates a bunch of peoples standards on exception handling. If you are reading through this, and see something that I missed, or are interested in expanding this list with some other interesting concepts that I have missed, ping me! I am open to any and all ideas.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>