OWSTIMER Cryptography Exception March 21, 2013

http://blogs.technet.com/b/stefan_gossner/archive/2010/05/10/common-problem-with-sharepoint-2010-system-security-cryptography-cryptographicexception-keyset-does-not-exist.aspx

Uninstalling Visual Studio will not resolve this issue as the registry settings which present this dialog are still active.

To configure the server to no longer show a dialog when an unhandled exception occurs, use the registry editor to delete the following registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger

On a 64-bit operating system also delete the following registry keys:

• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
• HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

Worth setting to Automatic the Protected Storage service?

 

Exception Best Practice July 6, 2012

http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

Don’t use exceptions to indicate absence of a resource

Microsoft recommends that you should use return special values on extremely common situations. I know I just wrote the opposite and I also don’t like it, but life is easier when most APIs are consistent, so I recommend you to adhere to this style with caution.

I looked at the .NET framework, and I noticed that the almost only APIs that use this style are the APIs that return some resource (e.g., Assembly.GetManifestStream method). All those APIs return null in case of the absence of some resource.

Exception Handling May 8, 2012

http://msdn.microsoft.com/en-us/library/ms229009.aspx

Tester-Doer pattern.

http://www.dotnetperls.com/tester-doer

Use when exception is likely.

http://www.codeproject.com/Articles/10255/Exception-Handling-Logging-Application-Block-Enter

Using the Exception Handling block.

http://enggtech.wordpress.com/2010/05/25/the-exception-handling-application-block-microsoft-enterprise-library-5-0/

Using the Exception Handling Block.

Client object model asynchronous object model exception handling February 28, 2012

http://www.novolocus.com/2012/02/27/handle-exceptions-in-client-object-model-callbacks/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+novolocus+%28novolocus+-+whatever+Andy+Burns+is+working+on%29

Client object model asynchronous object model exception handling.

 

 

 

WPF “DispatcherUnhandledException” handler to “App.xaml” November 9, 2011

http://www.codeproject.com/KB/WPF/MVVMQuickTutorial.aspx

The View-Model class that we just implemented throws “Exceptions“. We need to handle these exceptions, otherwise the application will stop. We will implement the exception handler in the code-behind file for the “App.xaml” file as the method “APP_DispatcherUnhandledException“:

Collapse | Copy Code

using System;
using System.Collections.Generic;
using System.Configuration;
using System.Data;
using System.Windows;
using System.Linq;
using System.Windows.Threading;

namespace WpfModelViewDemoApplication
{
    public partial class App : Application
    {
        private void OnStartup(object sender, StartupEventArgs e)
        {
            Views.MainView view = new Views.MainView();
            view.DataContext = new ViewModels.MainViewModel();
            view.Show();
        }

        private void APP_DispatcherUnhandledException(object sender, 
            DispatcherUnhandledExceptionEventArgs e)
        {
            MessageBox.Show(e.Exception.Message);
            e.Handled = true;
        }
    }
}

In order that the exception handler catches the exceptions, we will need to modify the “App.xaml” file to set the “DispatcherUnhandledException” property in the “<Application />” tag to “APP_DispatcherUnhandledException“:

Collapse | Copy Code

<Application x:Class="WpfModelViewDemoApplication.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    DispatcherUnhandledException="APP_DispatcherUnhandledException"
    Startup="OnStartup">
    <Application.Resources>

    </Application.Resources>
</Application>

This exception handler only catches unhandled exceptions thrown from the UI thread. If the application has worker threads that also throw exceptions, these exceptions need to be “Dispatched” to the UI thread to be caught by this handler.

 

Patterns and Practices Exception Handling Application Block October 7, 2011

http://msdn.microsoft.com/en-us/library/ff649552.aspx

Exception Handling Application Block

http://codebetter.com/davidhayden/2005/03/04/enterprise-library-cache-and-configuration-application-blocks-patterns-and-practices/

Examples

SPUpdatedConcurrencyException on SPPersistedObject May 24, 2011

http://sharepointoccasionaltip.blogspot.com/2009_03_01_archive.html

catch (SPUpdatedConcurrencyException)
    {
        count++;
        if (count > 10)
        {
            throw;
        }
    }

Exception In Constructor February 1, 2010

http://www.dev102.com/2008/12/03/throwing-exceptions-from-constructors/

Exception Handling Best Practice December 19, 2009

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx#Don%27tclearthestacktracewhenre-throwinganexception20

As we’re talking about logging, don’t forget that you should always log Exception.ToString(), and never Exception.Message. Exception.ToString() will give you a stack trace, the inner exception and the message. Often, this information is priceless and if you only log Exception.Message, you’ll only have something like “Object reference not set to an instance of an object”.

Microsoft recommends that you should use return special values on extremely common situations. I know I just wrote the opposite and I also don’t like it, but life is easier when most APIs are consistent, so I recommend you to adhere to this style with caution.

I looked at the .NET framework, and I noticed that the almost only APIs that use this style are the APIs that return some resource (e.g., Assembly.GetManifestStream method). All those APIs return null in case of the absence of some resource.

Instead of “throw ex;“, which will throw a new exception and clear the stack trace, we have simply “throw;“. If you don’t specify the exception, the throw statement will simply rethrow the very same exception the catch statement caught. This will keep your stack trace intact, but still allows you to put code in your catch blocks.

Visual Studio Break On Exception November 3, 2009

To break execution when an exception is thrown

1. On the Debug menu, click Exceptions.
2. In the Exceptions dialog box, select Thrown for an entire category of exceptions, for example, Common Language Runtime Exceptions.-or-

   Expand the node for a category of exceptions, for example, Common Language Runtime Exceptions, and select Thrown for a specific exception within that category.