Standardize error messages

[spawnia]

Right now the error messages that are thrown are pretty messy.

We should standardize them to make them more predictable and uniform.

• Should we terminate messages with a dot .?
• How do we quote things like class names? Backticks, Single or double quotes, square brackets, not at all?

[olivernybroe]

Thumbs up on this comment if you think we should terminate with dot.

[alberthaff]

@olivernybroe I agree. This definitely makes longer errors messages easier to read.

I think it would also make errors easier to read, if we placed URLs referring to docs, etc. at the very end.

// Current Exception message

Error
'Could not find a valid map, be sure to conform to GraphQL multipart request specification: https://github.com/jaydenseric/graphql-multipart-request-spec'


// URL to docs at the end

Error
'Could not find a valid map. Be sure to conform to GraphQL multipart request specification. Instead got: null. (see: https://github.com/jaydenseric/graphql-multipart-request-spec).'

[JasonTheAdams]

Hi! Jumping in here to see what I can find. 😃

I'm starting with an audit of how exceptions are currently generated, as well as the messages they provide.

Test-Only Exceptions

The following are exceptions that are only thrown during tests. I suggest creating a tests/Exceptions directory for these. Exceptions within src/Exceptions should be limited to exceptions used during runtime.

• AuthenticationException

Unused Error Code

The following are classes/exceptions that do not currently have any use within the codebase.

• HasErrorBuffer (trait)
• HasErrorBuffer (interface)
• ErrorBuffer

Note on ErrorBuffer: It is used by the trait, which is not used. It is used by the interface, which is checked for in FieldFactory but is never implemented.

---

This is a work in progress. I'm still doing research and will edit this comment over the next couple days with more details.

[spawnia]

@JasonTheAdams looks great so far!

Another thing i would like to change is to get rid of the DirectiveException in favour of DefinitionException - the latter should be used to clearly indicate when the error originates from a faulty definition.