A forgotten corner.-exception (iii)

In the previous article mainly introduces several ways of log, then say the way of notice:

Notification mode	Description
Email	This is the most common and most convenient way to notify. Advantages: Use simple disadvantages: need to rely on the SMTP server, etc.
Sms	This is also the current more popular way of notification, but generally do not send all the information through SMS, you can select a few more critical exception SMS notification. Disadvantages: Words, gateways, interfaces and other restrictions. Advantages: Timeliness
Post	Post Exception the client through a service. Advantages: Timeliness (but dependent on the client) disadvantage: A secure client program needs to be written.
Get	Similar to post advantages, but need to save the exception to a place, and then get the time.
Other	There are many ways of informing, depending on the needs of the people.

Generally we use the first 2 ways, because the writing is also very simple, SMS interface is now a lot of.

Note: If you have an email program in your program, I recommend that you do not use the same configuration for sending, and suggest that you re-establish a new configuration, including the way you send it using a new method.

It is worth noting that when your email notification method throws an exception, please be sure to use a different way to notify, because at this time your site may have occurred a noticeable exception.

The information of the notification is relatively simple, if it is sent by email, you can use log log information to send, if SMS, you can use a template, or a fixed format to send.

The content of the notice is not much, let's discuss Try/catch

This question was originally meant to be said, a few days ago also saw the Yang brothers "please discuss" which the discussion is very encouraging, many people say is more correct, so I think maybe my plan is not the best, but I decided to still write my opinion, so that we can discuss together. Lao Zhao said in the internal class when the best also can be caught after the exception, packaging and then throw, but I personally think, if it is class library, or not to catch, this is why?

I think that the method in the class library is the smallest unit of our program, its existence is for our high-level call, its existence must have its meaning, even if it calls the other class library method (most will call FCL), we had better not go to catch up, but some times you may want to violate this rule, but please remember, Encapsulate your exception and then throw to the top so that you don't omit exception from your program. A method in a class library, if you call a lot of other library methods, you should consider that your class library may already have several possibilities to change your results, and you should redesign your approach well.

Now, in my opinion, our web site uses a three-tier architecture, but in order to decouple the business logic from the page layer, we use some patterns to reduce its coupling. (Own ideas, maybe some of the concepts will be wrong)

Most of our site is the database of the I, U, D, s operation, so the data layer has basically belonged to the underlying class library, business layer to make calls, the UI layer to display information. (Are we not dealing with the anomaly of the data layer?) Also not necessarily, if according to what I said earlier, the best is not at the bottom of the processing, there is no fault, but we can not be too absolute, or according to your project to analyze after the arrangement. ）

Some people will say that in the data layer, we will use ADO and other methods, and the database will be a certain link, which will throw a variety of anomalies, do not we do not deal with it? Yes, if possible, please do not handle here, my solution is to go to the business layer for capture and processing.

Business layer are we going to take care of all the anomalies? Please do not think so, because some of the exceptions are not all you can deal with, we should be able to predict the exception we need to deal with (let us define our handler as ExceptionManager) into the ExceptionManager for processing. But we sometimes need to throw some exception message to the user, so these exceptions, please package well, continue to the top throw, at this time, please do not throw the exception to ExceptionManager, because we will have other places to deal with later.

To this, the turn of our UI layer, the UI layer is directly facing the user, in our previous said, we must record our exception, so that users present a friendly user interface, that is to do the king of the site. In web.config, you can set a page URL that is rendered when an error occurs. Although this can give users a good friendly interface, but sometimes, we need to provide users with more information, such as input user name, such as the Config configuration page can not meet our requirements, then how do we do it?

In fact, it's easy to use a httpmodule, and don't involve anything else in this module, Because in ASP.net, the order of a request will execute all of your module once, so don't worry. NET will be omitted, we just need to configure well. So what do we do as a module? To handle only unhandled exceptions, look at a piece of code first:

Exceptionhandlingmodule

1public class Exceptionhandlingmodule:ihttpmodule
2 {
3 IHttpModule members #region IHttpModule members
4
5 public void Dispose ()
6 {
7
8}
9
Ten public void Init (HttpApplication context)
11 {
The context. Error + = new EventHandler (context_error);
13}
14
void Context_error (object sender, EventArgs e)
16 {
var application = (HttpApplication) sender;
18
19//Get the previous error of the current request
20//The GetLastError here is actually a package of good exception
21//We need to get the InnerException property if we want to know the real exception.
var unhandlingexception = Application. Context.Server.GetLastError ();
if (unhandlingexception!= null)
24 {
Unhandlingexception = unhandlingexception.innerexception;
if (unhandlingexception!= null)
27 {
Exceptionmanager.handlingexception (unhandlingexception);
29
30//All right, we've got the unhandlingexception handled.
Application. Context.clearerror ();
32
33//Of course, if you want the user to see the error message, remember to keep it.
34}
35}
36}
37
#endregion
39}

The third chapter is here, then will be the custom exception, the processing of the code to explain to everyone.

In fact, a lot of content is modified, the original idea in my blog, feel more and more wrong, it seems that I have to add strength, some places may not be very reasonable, and I hope that everyone can give me suggestions, lest mislead other readers: