HandleError not hit

[bonesoul]

As stated in https://github.com/bernos/Nancy.CustomErrors, I've overriden handleerror but somehow it's not hit (have put a breakpoint there)

    public class ErrorConfiguration : CustomErrorsConfiguration
    {
        public ErrorConfiguration()
        {
            // Map error status codes to custom view names
            ErrorViews[HttpStatusCode.NotFound] = "error";
            ErrorViews[HttpStatusCode.InternalServerError] = "error";
            ErrorViews[HttpStatusCode.Forbidden] = "error";
        }
   public override ErrorResponse HandleError(NancyContext context, Exception ex, ISerializer serializer)
        {
            var error = new Error
            {
                FullException = ex.ToString(),
                Message = ex.Message
            };

            return new ErrorResponse(error, serializer).WithStatusCode(HttpStatusCode.InternalServerError) as ErrorResponse;
        }
    }

        protected override void ApplicationStartup(TinyIoCContainer container, IPipelines pipelines)
        {            
            CustomErrors.Enable(pipelines, new ErrorConfiguration());
        }

any ideas?

[bernos]

Hi there. Is it possible that you have another middleware in the pipelines.OnError pipeline? CustomErrors adds its handler to the end of the pipeline, so it is possible that something earlier in the pipeline is preventing the CustomErrors handler from being called

[bonesoul]

Yes I do have https://github.com/etishor/Metrics.NET within the pipeline though not sure if it's is breaking the stuff.

[bernos]

Ah. Just a quick look a the source code at https://github.com/etishor/Metrics.NET/blob/7c5c3d3bff416ab8b7a0a300bacf7b327748de85/Src/Adapters/Nancy.Metrics/NancyGlobalMetrics.cs on line 80 it adds a handler to the start of the OnError pipeline. That could have something to do with it. If you temporarily disable the Metrics module and stimulate an error does you custom ErrorConfiguration.HandleError method get called?

[etishor]

I'm also looking into this now, but the handler registered by the Metrics.NET library is always returning null, which should not affect how the other handlers are executed.

I've managed to isolate an issue in this gist: https://gist.github.com/etishor/924ee47086222bf9a780

Without the CustomErrors package this works fine. Just by adding the nuget package for CustomErrors the request to /test hangs.

Anyway, I'll add in Metrics.NET a config option that will allow returning http status 200 even if health checks fail. This should allow using CustomErrors together with Metrics.NET.

It might be an idea to add a config options to CustomErrors to ignore a particular route.

[etishor]

I've added (etishor/Metrics.NET@53bf39e) an option in Metrics.NET to configure the health checks endpoint to return HTTP Status 200 even if checks fail.

[bernos]

Sorry for not responding sooner guys... I've had another look at this issue and can see that it would actually occur if one of your configured error views cannot be located. Can you confirm that your error views are already set up? I'll look at handling the view not found exception explicitly and returning something helpful.

[bernos]

Another thing. I realise now that the naming of the ErrorConfiguration.HandleError method is probably not semantically correct.

The role of that method is to map a thrown exception to a properly populated ErrorResponse. It exists for use cases where a layer further down (say, your domain layer) throws a domain specific error back to your HTTP layer (NancyModule) and you need to map it to something other than a generic Response with HttpStatusCode.InternalServiceError. Say, for example you have an auth service somewhere that throws a CustomNotAuthorisedException, and you'd like nancy to emit a NotAuthorised response.

Sooo... If you are returning any "error" status code and Response from a NancyModule, HandleError will never be called, as there is no exception to map to a Response. You've already constructed and returned the response.

I realise that this is not very obvious from both a documentation and method naming perspective. I'll make some updates to both in the next release.

[etishor]

@bernos in the gist I've setup no views. The point was being able to reproduce the request hanging - which should not happen even if no view is configured. Also note that in the code to reproduce the request hanging, I've only added the NuGet package for Nancy.CustomErrors without any configuration or code.

I'm not personally using the Nancy.CustomErrors (I might in the future) - I was just trying to make sure there is no incompatibility with Metrics.NET.