Esbaop Application -- Exception Shutdown

Based on my own exception handling experience, I usually intercept all exceptions in the UI event processing function or the thread startup function, and then perform specific processing on the intercepted exceptions-in many cases, is to display an error message to the user, or record exception logs! In this "many cases", I need to do the same job. First, try... catch enclose all the code in the UI event handler function or the thread startup function. Then, it may be MessageBox. show (ex. message) or other processing.
We have already thought that AOP can be used to accomplish this kind of thing. This article will develop an exception blocker-exceptioncloseeraspect Based on the esbaop introduced earlier. It will modify the UI operation or the startup function of the background thread, it is used to control whether to intercept the exception thrown by the modified method. If intercept is performed, the exception is user-defined and then disabled.
For predictioncloseeraspect, pay attention to the following aspects:
(1) During UI operations or background threads, the database or network is often accessed. To intercept these exceptions, you need to write try in each UI event handler... catch: If you use exceptioncloseeraspect, you do not need to write try-catch. exceptioncloseeraspect automatically intercepts exceptions and closes them.
(2) exceptioncloseeraspect is usually used at the top of the system structure, such as at the UI Layer or at the startup function of the background thread. And the return value of these functions is void.
(3) users can customize the Exception Handling Scheme by implementing iexceptionhandler, such as recording exception logs and notifying users by pop-up message boxes.
(4) Note: Generally, the UI inherits from form, so it cannot be inherited from contextboundobject, and aspect cannot be used for it, therefore, we need to encapsulate the upper-layer logic in a separate class =, which facilitates the separation of UI and logic!

The preceding analysis shows that there are two types of threads: the main thread (usually the UI thread) and the background thread, and the exception thrown by different threads, the user may need to perform different processing. Therefore, we use enumeration to define the thread type: // <summary>
/// The type of the thread in which the exceptionclosetype exception occurs
/// </Summary>
Public Enum exceptionhosttype
{
Notsetted, uithread, backgroundthread
}

To give users the opportunity to handle thrown exceptions, we provide the iexceptionhandler interface: // <summary>
/// Before the iexceptionhandler closes an exception, you can use the custom iexceptionhandler to handle the exception, for example, record it as a log or Display Error information to the user.
/// </Summary>
Public interface iexceptionhandler
{
Void handleexception (exception EE, exceptionhosttype hosttype );
}

Based on these, we can implement predictioncloseeraspect. As you can see from the past, predictioncloseeraspect only needs to implement the iaspect interface. Now we provide its implementation: public class exceptioncloseeraspect: iaspect
{
Public exceptioncloseeraspect ()
{
}

# Region iaspect Member
Public void preprocess (imethodcallmessage requestmsg, object aspectclassargument, object aspectmethodargument)
{

}

Public void postprocess (imethodcallmessage requestmsg, ref imethodreturnmessage respond, object aspectclassargument, object aspectmethodargument)
{
If (respond. Exception = NULL)
{
Return;
}

Type handlertype = (type) aspectclassargument;
Type desttype = typeof (iexceptionhandler );
If (! Desttype. isassignablefrom (handlertype ))
{
Return;
}

Iexceptionhandler exceptionhandler = (iexceptionhandler) activator. createinstance (handlertype );
If (aspectmethodargument! = NULL)
{
Exceptionhandler. handleexception (respond. exception, (exceptionhosttype) aspectmethodargument );
}
Else
{
Exceptionhandler. handleexception (respond. exception, exceptionhosttype. notsetted );
}

// Modify the returned result and disable the exception.
Respond = new returnmessage (null, requestmsg );
}

# Endregion
}

The preceding implementation must be described as follows:
(1) exceptioncloseeraspect's aspectclassargument is the type that implements the iexceptionhandler interface.
(2) The aspectmethodargument of predictioncloseeraspect is one of the predictionhosttype enumeration values.
(3) Note that the last sentence of the postprocess method implementation is that AOP modifies the result of the method call and closes the exception.

After implementing the exception shutdown, we can try it out. First, we need to implement the iaspectprocessorwrap interface to reflect the resources required by predictioncloseeraspect:

Public class exceptionclosserwrap: iaspectprocessorwrap
{
# Region iaspectprocessorwrap Member

Public type aspectprocessortype
{
Get
{
Return typeof (exceptioncloseeraspect );
}
}

Public object aspectclassargument
{
Get
{
Return typeof (exceptionhandler );
}
}

Public writable iseserverbase. AOP. multiaspect. aspectswitcherstate defaultaspectswitcherstate
{
Get
{
Return aspectswitcherstate. on;
}
}

# Endregion
}

We also need to implement iexceptionhandler to handle exceptions:

Public class exceptionhandler: iexceptionhandler
{
# Region iexceptionhandler Member

Public void handleexception (exception EE, exceptionhosttype hosttype)
{
If (hosttype = exceptionhosttype. uithread)
{
MessageBox. Show (EE. Message + "UI thread! ");
}

If (hosttype = exceptionhosttype. notsetted)
{
MessageBox. Show (EE. Message + "host thread not setted! ");
}

If (hosttype = exceptionhosttype. backgroundthread)
{
MessageBox. Show (EE. Message + "background thread! ");
}
}

# Endregion

}

The previous code can easily understand that exception handling only displays the exception information to the user. Now let's take a look at how to use exceptioncloseeraspect. It should be emphasized that predictioncloseeraspect usually acts on the UI event processing function or the thread startup function. We have a UI event handler function as an example. First, we must ensure that the UI is separated from the business logic. Therefore, I encapsulate the business logic in the mybusiness class:

[Aspect (typeof (exceptionclosserwrap)]
Public class mybusiness: contextboundobject
{
[Aspectswitcher (typeof (exceptionclosserwrap), true, exceptionhosttype. uithread)]
Public void onbutton1click ()
{
Throw new exception ("Sky test exception! ");
}

[Aspectswitcher (typeof (exceptionclosserwrap), true)]
Public void onbutton2click ()
{
Throw new exception ("sky2 test exception! ");
}

[Aspectswitcher (typeof (exceptionclosserwrap), true, exceptionhosttype. backgroundthread)]
Public void skythread ()
{
Throw new exception ("background thread exception! ");
}
}

In all UI event processing functions, the corresponding methods of mybusiness will be called, such:

Private void button#click (Object sender, system. eventargs E)
{
This. mybusiness. onbutton1click ();
}

Private void button2_click (Object sender, system. eventargs E)
{
This. mybusiness. onbutton2click ();
}

Private void button3_click (Object sender, system. eventargs E)
{
Thread thread = new thread (New threadstart (this. mybusiness. skythread ));
Thread. Start ();
}

You can write a copy of the above example to see the running result. The following sample source code is also provided for download!

Sample download