Skip to content

Exception handling #42

@richardp-au

Description

@richardp-au

I'd like to return different error messages to the user to attempt to explain the problems better. For example, rather than say that an API doesn't exist, I'd like to tell them if:

  1. They've omitted the version from the Accept header completely. I'd rather report this in a nice way than have a default version number.
  2. They've supplied an invalid version in the Accept header. This could just end up being the same as above.
  3. They've asked for a version number that doesn't exist (on any route). I'm not sure that this would be possible or not but it feels nicer than just saying that the API wasn't found when in fact that version number is not ever used.

I also found that I get The API 'SDammann.WebApi.Versioning.ControllerIdentification' doesn't exist returned when I omit the version header. Not sure why it's referring to a namespace that isn't mine but it's definitely not clear to users what's going on.

The problem is that since the code throws HttpResponseExceptions, I'm unable to handle them in a global error handler.

What do you think about either changing the type of exception thrown so it can be caught in the global error handler and handled appropriately, or even providing an error handling class that can be derived and injected into the configuration?

At the moment, the best I've come up with is deriving from VersionedApiControllerSelector and wrapping OnSelectController in a try/catch block so I can create a different response and throw another HttpResponseException. It would be nice to have a cleaner way of doing this.

(Using v3.0.0-beta1.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions