Using ASP.NET MVC 5 and the Xero.API.SDK.2.2.1.13.
I'm trying to handle all possible errors thrown when calling the Xero Api. I'm attempting this through over riding the OnException action within my BaseController. This successfully catches all errors thrown but I am unable to access the list of ValidationErrors which appears to be contained within the filterContext object (see below) when I'm debugging. I'm also unable to create a XeroApi.ValidationException object from the filterContext object.
Does anyone know how to access the ValidationErrors in this instance? Or have a more suitable way of handling all xero and other related errors within a single controller?
protected override void OnException(ExceptionContext filterContext)
{
//Below line results in error: "cannot convert System.Exception to
ValidationException. An Explicit conversion exists".
ValidationException ex = filterContext.Exception;
Exception ex = filterContext.Exception;
filterContext.ExceptionHandled = true;
}
Answer provided by Henzard Kruger on the Xero Community forum:
Just hack the Xero dll. You need to deal with the error in https://github.com/XeroAPI/Xero-Net/blob/master/Xero.Api/Infrastructure/Http/XeroHttpClient.cs#L105 then just recompile the DLL.
Issue was resolved after following the above advice.
Related
I have this simple controller, whose Get method is called with ajax to look up zipcodes via an Entity Framework repository.
[Authorize]
public class ZipCodesApiController : AppApiController
{
public ZipCode Get(string zipCode)
{
return unitOfWork.ZipCodeRepository
.Get(x => x.Zip == zipCode)
.FirstOrDefault();
}
}
In production, my logs show that System.OperationCanceledException: The operation was canceled. is thrown quite often. I think what's going on is that users are viewing an address detail page, but navigating away or closing their browser before the ajax zipcode lookup returns. I guess IIS is telling my controller that they are no longer connected, and the .NET framework throws an exception?
This seems harmless, but it also seems like a bad idea to wrap the call to ZipCodeRepository in a try and have an empty OperationCanceledException catch clause.
I've googled the error and it seems to come up quite a bit in parallel programming, which is not something I am particularly familiar with.
What is an appropriate way to handle this exception? I think it's safe to ignore, but am I wrong about that, and the Entity Framework should be alerted so that it can clean something up (my AppApiController does have a dispose method at least)?
I get the same exceptions in my web API application, however i can catch them with the Application_Error method in Global.asax.cs
protected void Application_Error(object sender, EventArgs e)
{
Exception exception = Server.GetLastError();
Response.Clear();
OperationCanceledException httpException = exception as OperationCanceledException;
if (httpException != null)
{
var token = httpException.CancellationToken;
if (token.IsCancellationRequested)
{
// clear error on server
Server.ClearError();
Request.Abort();
}
}
}
I don't know if that is right.
I have enabled the global error handling for an application by applying the HandleError attribute within the filterConfig registration.
public class FilterConfig
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}
}
I am then using the custom errors (web.config) to hopefully display a friendly error message for each server error.
<customErrors mode="On" ></customErrors>
This seemed to be working fine for most exceptions and I was getting the expected behaviour in that the custom error page View (Error.cshtml in the shared view folder) was being displayed.
However I have recently noticed that this is not the behaviour I see if the error thrown is an UnauthorizedAccessException.
I am a bit stumped with this, as looking in fiddler I see that this UnauthorizedAccessException exception returns a plain 500 internal server error as a standard exception does.
So how come the standard exception abides by my customError setup but the UnauthorizedAccessException does not?
ANd how can I get them to behave the same, as they are both essentially an error which I want to prevent the end user from seeing.
This blog post provided me with the overview of exception handling to enable me to decide how to handle the unauthorizedAccessException, which essentially means handling them within the Application_OnStart.
http://prideparrot.com/blog/archive/2012/5/exception_handling_in_asp_net_mvc
For my purposes there doesn't seem much point in handling the errors with the HandleErrorAttribute and in the global Application_OnStart so for my purposes I decided it was best to handle everything in the Application_OnSTart,
If you just want to force 'unhandled' exceptions like UnauthorizedAccessException to go through the normal custom-error page then you can override the controller's OnException method similar to the following:
protected override void OnException(ExceptionContext filterContext)
{
base.OnException(filterContext);
if (!filterContext.ExceptionHandled && filterContext.RequestContext.HttpContext.IsCustomErrorEnabled)
{
filterContext.ExceptionHandled = true;
filterContext.HttpContext.Response.StatusCode = (int)System.Net.HttpStatusCode.InternalServerError;
filterContext.Result = View("Error",
new HandleErrorInfo(filterContext.Exception, filterContext.GetCurrentControllerName(), filterContext.GetCurrentActionName()));
}
}
The article that you referenced is an excellent resource for a more thorough explanation of error-handling techniques, though, and should be considered as well.
I have mvc 3 application which when a Standard generic throw new Exception is thrown in code the error page from Views\Shared\error.cshtml is shown. This is done by simply setting <customErrors mode="On"/>. (This is As expected and as Desired)
The application is using WCF services in middle tier which when these services generate FaultException MVC is not showing up the error page it is showing details of the web service call to the user on screen. All I want to do is handle the error in my code and show the user the Error.cshtml. I have tried changing global asax but this dosent work.
protected void Application_Error(object sender, EventArgs e)
{
Exception exception = Server.GetLastError();
if (exception.GetType() == typeof(FaultException))
{
throw new Exception("There was a fault exception that i do not want to show details of to user.");
}
}
Try creating an ErrorController as asp.net MVC will try to resolve the link you specified in the web.config as {Controller}/{View} unless you specify it to ignore that page. Also, you may want to apply an attribute to handle exceptions instead.
You can also create a error controller/view and in your catch block redirect to the custom error page of your choosing
try
{
foo.bar()
}
catch(SpecificException)
{
RedirectToAction("500", "Error");
}
All I need would be just the error message in plain text. But ASP.NET is doing some HTML report output from every error.
I have a jquery ajax call and when an error is thrown I'm getting all that crap over to the client side.
I've created a filter attribute but didn't helped.
public class ClientErrorHandler : FilterAttribute, IExceptionFilter
{
public void OnException(ExceptionContext filterContext)
{
var responce = filterContext.RequestContext.HttpContext.Response;
responce.Write(filterContext.Exception.Message);
responce.ContentType = MediaTypeNames.Text.Plain;
filterContext.ExceptionHandled = true;
}
}
EDIT
I'm seeing this
and I'd like to see just what is in here filterContext.Exception.Message
It looks to me like the reason why you cannot correctly handle the exception is because it happens outside of the MVC pipeline. If you look at the stack trace in the code you posted there is no reference to System.Web.Mvc code (the firing of exception filters when an exception occurs is called from ControllerActionInvoker.InvokeAction).
The stack trace indicates that the exception happens late in the ASP.NET pipeline (OnEndRequest) and that it's coming through the Autofac component.
To capture this error you would have to subscribe to the HttpApplication's Error event. See the following article on creating a global error handler: http://msdn.microsoft.com/en-us/library/994a1482.aspx . In this event you can handle the error and redirect to a custom error page.
you need to return a ContentResult
ContentResult result = new ContentResult();
result.Content = filterContext.Exception.Message;
result.ContentType = MediaTypeNames.Text.Plain;
filterContext.Result = result;
filterContext.ExceptionHandled = true;
Since you're using JQuery and WCF (by the details of your error), you might want to take a look at this article on how to handle service faults elegantly between jQuery and WCF - you might have to rework your service if you are able to do so.
i'm trying to send back a simple error message as Json, with the HTTP code as 404.
So i started out writing my own IExceptionFilter that checks to see the exception. To keep this simple, if the exception throw is of type ResourceNotFoundException then i set the code to 404. Otherwise everything else if 500.
Now, the problem is .. the default IIS7 404 error message is returned :( my code is called .. but it seems to bypass it (later on in the pipeline)...
is there some trick i need to do?
do I need a custom error handling (in the web config) to be turned on or something?
Edit:
I'm trying to do what twitter does. Their Http Response Code documentation shows / explains some examples how they handle 404's, etc.. and i'm wanting to do that in my MVC app.
Edit 2:
The code i've done is listed here, for anyones reference :)
When you are handling your exception, are you setting ExceptionHandled to true?
Here's a quick example...
HandleException(ActionExecutedContext filterContext)
{
Exception exception = filterContext.Exception;
//Check if our exception has been handled.
if (filterContext.ExceptionHandled == false)
{
//Do your exception stuff
filterContext.Result = YourExceptionMessageAsAnActionResult();
//Set it as null.
filterContext.ExceptionHandled = true;
filterContext.HttpContext.Response.Clear();
}
}