Model State Errors (or) Custom exceptions of a certain type

Question

0.00/5 (No votes)

See more:

Hi All,

I have an application ASP.NET MVC with JQUERY application that throws 4 kinds of errors

Unhanded exceptions (400, 403,500 503 etc) - throw generic exceptions
NOT SEVERE Expected exceptions/ errors (custom exceptions)- e.g. Trying to look for a contact that does not exist in the system - The system needs to throw "Contact_not_found_exception" and show this to the user as "Contact does not exist in the system" . It does not stop the user from doing anything else but its just to alert the user
VERY SEVERE Expected exceptions/ errors (custom exceptions)- e.g. Trying to create a contact that already exist in the system - The system needs to throw "Contact_duplicated_exception" and show this to the user as "Contact was previously created. Could not proceed as name should be unique"
Model state errors (UI). Errors that I add to modelstate to showup on the page using @Html.ValidationSummary(true)

Client validation errors which are caught on the front end and application errors are caught in global.asax

I am looking for a good way to catch errors/exceptions of type 2 and 3 and return it back to AJAX() Calls with a certain severity type "Critical" vs "Warning".

I have been following the link for Handling validation errors on Ajax calls in Asp.net MVC

http://erraticdev.blogspot.com/2010/11/handling-validation-errors-on-ajax.html

I cannot generalize and add all the model state errors as ModelStateException. As most of these errors/exceptions are of a certain severity type and my front end (JQUERY) should read this type of error and do different actions.

1.How do I create a dictionary of custom exception , severity type ? 2.How do I throw these and add it to model state error. 3.How do I catch these globally using Custom Handle Erro Arrtibute and IExceptionFilter

Thanks,

Posted 13-Aug-13 6:19am

hlobo123

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2013-08-13T06:34:00

Thrown are exceptions, not errors. Exceptions are not errors (surprise? :-)). Exceptions cannot be "returned".

Also, there are no good or bad ways of catching exceptions, there is only one, try-catch-finally block. More important thing is where to catch them (many beginners catch way too much without a good purpose) and what to do to handle them. It generally needs understanding of exception mechanism and the mechanism of propagation.

Now, you cannot throw an exception on the server side and catch it on the client side. Not only because the sides are separated by the network (there are the ways to thunk exceptions through marshaling and re-throwing on the other side), but mostly because exceptions on .NET and JavaScript have different incompatible nature, implementation.

Therefore, you need to catch all exceptions of your ASP.NET application on server side, on the very top stack frame, and classify it by handling several known base types of exception. Don't forget to catch all other exception by handling the very root type, System.Exception, at the very end of the try-catch block (before finally, if you have the finally part); such exceptions could be classified as "others" or something like that.

In your HTTP request, create a structure which can be laid out as plain text and passed back to the client. Ajax will be able to parse this text and show exception information the way you program it on the page. If such shared exception structure appears to be rather complex, consider this text to be XML or JSON. This way, you will be able to generate the exception structure on server side and parse it in JavaScript. Naturally, most convenient form for JavaScript is JSON.

—SA