Scenario: Site uses Mvc async controller.
Error: Everytime an async end operation (like EndReceive) throws an error it also crashes IIS.
This is the type of error one should always try to catch but is the default behavior otherwise always crashing the IIS process? (don't know if i should leave it or start more in depth troubleshooting)
Thanx,
I think you will find the following blog post useful in understanding what happens under the covers.
Related
I have a web application with the following layers:
Client(s)
WebAPI
Services
Repository
Core
I'm not sure where to put error handling though. Within the webAPI controllers, should I just have try/catch statements? Is it ok to throw errors in the services/repository code? I'm trying to avoid passing any data to the client, other than some friendly error message.
Business errors should be handled in your service layer (for example things like username already exists). Putting try/catch statements in all your controller actions could quickly become cumbersome and lead to repetitive code. You may take a look at the custom error handling article which provides examples of handling various errors in the Web API such as custom error filters (deriving from the ExceptionFilterAttribute class and overriding the OnException method).
You can create a custom exception type that would be intercepted by an ExceptionFilter or http module. It would set the HTTP status code and description. Optionally, it can also return a serialized object with the error data.
Other exception types would return status code 500.
I have a custom ActionResult which is more deeply encountering System.Web.HttpException when the remote host closes the connection. I've already overridden the Controller's OnException method but it's not getting caught there. The ASP.NET MVC pipeline is already done executing my Controller's Action and is now executing the returned ActionResult when it encounters this exception.
Presently, it's bubbling up and being cluttering my log as an ERROR. I'd rather not filter these out at logging time, because I don't consider a remote host aborting the download of the content to be an error.
I'd rather handle this error directly, but I can't tell where. Controller.OnException doesn't work, and so I doubt the IExceptionFilter would either. I could use Application_OnError but I fear that is too high up.
Isn't there a more MVC'ish way?
There are no other points to catch exceptions between Controller.OnException and Application_OnError. Be Brave and use Application_OnError
You can use HandleErrorAttribute to handle exceptions thrown in the controller action. As you pointed out in your question, I would suspect the error is beyond the scope of this attribute. That would leave only Application_OnError.
You could add a whitelist to your error handling code to ignore specific errors (specific type with specific code and maybe specific source/stacktrace).
Due to ongoing issues with ASP.NET MVC 4 and WebAPI, see link:
MVC 4 Web API - CreateResponse(status, object) causes HTTP 500
I need to instrument the internal Web API pipeline and see what's going on.
How do I do this?
Thanks
Luke
**UPDATE **
I have an ITraceWriter now implemented and I can now see that there's an Exception property on the TraceRecord which I can dump or even break around, maybe.
Thanks, I think answers the question.
More info here:
http://www.asp.net/web-api/overview/testing-and-debugging/tracing-in-aspnet-web-api
you can enable all levels of tracing (from the basic, "info" tracing) for the entire stack.
If you use one of the popular libraries (i.e. nLog), you can easily write it all to file or event log if you wish.
just replace the default ITraceWriter with your custom class:
GlobalConfiguration.Configuration.Services.Replace(typeof(ITraceWriter), new NLogger());
You'll see all kinds of internal tracing messages filling up the logs.
I blogged about that here http://www.strathweb.com/2012/06/using-nlog-to-provide-custom-tracing-for-your-asp-net-web-api/
Have you tried setting:
GlobalConfiguration.Configuration.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
This is good post on Error Handling and tracing in Web API.
Which is the best way to handle a system error in ASP.NET MVC? I've watched a video on DimeCast.net in which the guy used the global.ascx file to write a method Application_Error to handle the errors. But currently, I'm handling my errors inside the web.config file.
Could someone point me in the right direction on how to properly handle errors? This could be:
syntax error
exceptions
404 and other page/file not found errors
The application is fairly large.
Take a look at elmah for logging of unhandled exceptions, there's actually a quick example on nuget demo video
I use combination of elmah for unhandled exceptions, and nLog to log ones that I can handle but still want to log. Thus far the combination has worked out very well.
Very likely you are going to need a combination of approaches. Some errors can be handled directly in your models, others in your controllers, and some others might need to be handled all the way to the application level (either via web.config or via the global.ascx.)
I prefer to handle the errors in the global.ascx rather than via redirection in web.config because in the global.ascx I have more information about the request that caused the error where as if I do a redirect via the web.config settings some of that information is lost by the time my error page receives the request.
A few weeks ago I just noticed that 404 errors are better not handled via the web.config because that (by design) causes an HTTP redirect code 302 rather than a true HTTP 404 code that indicates the client that the resource does not exist. I have a post on my blog where I cover this in detail http://hectorcorrea.com/Blog/Returning-HTTP-404-in-ASP.NET-MVC
Using ELMAH as Brook suggested is also a very good idea.
Error: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
http://servername/ScriptResource.axd?d=EltQ7pexCbRndWc7D3a....b2a49de
Line: 5
I recently converted a SmartPart + UserControl web part to a 'real' web part. The user control part remained essentially unchanged and contains an UpdatePanel. The aim is to have an interactive calendar control which updates its own data but does not cause a full page refresh. The main reason for converting to a real web part is to make use of personal storage so that users can choose a particular setting and store it.
The problem I now have is that when one of the LinkButtons in my web part are clicked I get the error listed above. I am not doing any Response.Writes and there don't seem to be any HttpHeader entries in IIS.
Can anyone help here? Thanks.
New clue
Just noticed that the postback events work when the page is checked out but not when it has been published. What is the significance of this?
Have you added the sharepoint script manager:
http://msdn.microsoft.com/en-us/library/ff650218.aspx
It sounds like a HttpModule is altering the json postback of the update panel