How hard is the unified Exception Handling of ASP. net mvc? (Derived intent, how to maintain the form state after an error ?)

A good development framework, we all hope that developers do not care too much about Exception Handling. Except for a specific exception, we all hope that many common exceptions can be handled by the framework. For example, we do not want developers to use the same or similarCodeComplete. Simply put, we don't want too many try... Catch code. In a project... Catch code blocks, on the one hand, the Code is not very elegant, on the other hand, it will also bring some obstacles to our code encoding, due to the variable scope (try and catch are different code blocks) problem, we often have to define variables in try... Block other than catch. Therefore, in many business logic code, we generally do not specifically handle exceptions. On the contrary, we often throw many business logic exceptions according to the needs of the business logic, thrown to the ui or service caller, and this exception is often a friendly message to the end user.

Therefore, it is the best choice to capture, process, and display exceptions in the UI code. Combined with the ASP. net mvc Framework, the unified Exception Handling solution is to rewrite the controller. onexception method or implement the actionfilter of the iexceptionfilter interface. However, can this really meet our unified Exception Handling needs? Let's take a look at the following situations:

1.

 
Public actionresult index () {VAR model = GetModel (); Return view (model );}
 

In this case, if an exception occurs during the GetModel operation, you can immediately capture and handle the exception and return to the index view without any useful information. At this point, it is acceptable to redirect to the unified and friendly error page. Therefore, in this case, the exception processing mechanism provided by MVC is very simple and effective to handle exceptions in a unified manner.

2.

[Httppost] public actionresult edit (user model) {If (modelstate. isvalid) {savemodel (model); Return redirecttoaction ("Index", "home")} return view (model );}
 

In this case, we assume that an exception occurs during the savemodel. This exception is not a systemic exception, but a business exception. We hope that the exception information will be displayed on the user's current operation page to keep the user input value unchanged. You only need to modify one or two input values based on the prompt message to submit the form again, instead of redirecting to the error prompt page, the system returns and completely enters the form again. Under this requirement, the exception handling mechanism provided by MVC cannot meet the requirements, because the model exception cannot be obtained in the unified Exception Handling context. Therefore, we can only add the exception handling code block:

 
[Httppost] public actionresult edit (user model) {try {If (modelstate. isvalid) {savemodel (model); Return redirecttoaction ("Index", "home") }} catch (exception e) {// log modelstate. addmodelerror ("", E. message) ;}return view (model );}
 

Such code is exactly what we want to avoid. However, such actions are everywhere in our system. However, if a certain precondition is met, assuming that our model variable names are "model", we may use actionexecutingcontext. actionparameters obtains the expected model value and provides it to the view. Through this kind of workaround und processing, we may be able to bypass this problem very well. Let's look at another situation:

3.

 
[Httppost] public actionresult edit (User user) {If (modelstate. isvalid) {savemodel (User);} VAR model = GetModel (user. name); viewdata ["title"] = "edit"; return view (model );}
 

In this case, we may not... Except catch, there is really no better way.

Exception Handling has always been a pain point in our software development process. WeProgramMembers are very scared. due to unexpected exceptions, our business modules may not run correctly and users may not be prompted to complain, but we do not like to do a lot of fragmented things because of these accidents that may not happen frequently, and it will make the code ugly. In general business systems, we do not add many catch clause to handle various exceptions in different categories. We have been working hard to make it easier and put exceptions within the controllable scope.