Custom Exception Handler

[namnm]

Is your feature request related to a problem? Please describe.
Thanks for the great package. Now I want to response the error based on some custom exceptions I threw.

Describe the solution you'd like
It should expose the default spec-compliant formatError function as: https://github.com/graphql/graphql-js/blob/master/src/error/formatError.js
Then it should allow to pass a custom formatError function to handle the error in the schema constructor.

[michaelstaib]

So, what do you want to achieve? Do you want to have a function that gets called whenever there is an exception and be able to format it? Or, do you want to be able to ensure that implementations of IQueryError are formatted correctly. In general the GraphQLError and GraphQLFormatted error do separate the concrete error from the serialization format.

[michaelstaib]

Sorry did not read your comment thoroughly enough. So, you basically want to be able to catch errors and reformat them. I think that is a good idea. Since I am rendering custom exceptions useless at the moment because I did not want to expose any compromising information of the server.

Let me have a look into how we can do that.

[michaelstaib]

Ok, I have looked at the implementation and we will include it with the next release. It might not be the next preview build so.

On the schema you will be able to add exception formatter like the following:

Schema.Create(c => 
{
    // handle all exception that are not explicitly handled.
    c.FormatException(exceptionContext => new QueryError("foo"));
   
    // handle specific exceptions, this will override the default handler.
    c.FormatException<FooException>(exceptionContext => new QueryError("foo"));
});

I will also create an interface IExceptionHandler that can be implemented and registered like the following as an alternative:

Schema.Create(c => 
{
    // handle all exception that are not explicitly handled.
    c.FormatException<MyHandler>();
   
    // handle specific exceptions, this will override the default handler.
    c.FormatException<FooException, MyHandler>();
});

The exception context will carry the thrown exception and also context data that was available when the exception was thrown like the field, object etc....

Would that meet your needs?

[namnm]

Yes, your idea has basically covered the case. And I think we need to expose the default error handler too.

public class MyExceptionHandler
{
    public QueryError HandleException(ExceptionContext ctx)
    {
        // We need to expose the default exception handler function as a static helper or something
        // So we can get the default QueryError and modify it instead of manually craft a new one
        var res = DefaultExceptionHandler.HandleException(ctx);
        // In this default QueryError it already has the context info such as path, line number...
        // We only want to modify the error message though
        // TODO modify res here based on the exception
        //
        return res;
    }
}

[michaelstaib]

OK, I will add that.

[michaelstaib]

#319

[michaelstaib]

Hi,

the exception filter will now look like the following:

public interface IErrorFilter
{
        IError OnError(IError error, Exception exception);
}

The exception formatter will not registered with the schema but with the dependency injection....
We are currently separating non schema relevant code from the schema .... execution services now are just registered with the solution....

You are able to add multiple exception filters which are called in the order of their registration.

so basically:

services.AddSingleton< IErrorFilter, MyFilter>()

Important: The exception can be null.

[michaelstaib]

The exception context is now not any more needed since each filter gets the exception and the error from the former filter .... so each handler could also add more details or remove details.....

[michaelstaib]

• Finalize implementation
• Tests

[michaelstaib]

Where can errors happen?

Basically errors can be provided as QueryException or as IError.

An error or exception can occur in the execution pipeline itself which could be handled in the ExceptionMiddleware.

Moreover, exceptions could occur when execution a field resolver pipeline. Also, the result of the field resolver pipeline could be an IError.

• Check if the field resolver exception are already serialized into an IError
• Check how the validation errors are handled

Ideally we can grab errors in a maximum of two or three places.

[michaelstaib]

#420

[michaelstaib]

We have completed this one and will include it in 0.7.0-preview.19