Skip to content

Error handling and logging #714

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 60 commits into from
Apr 8, 2020
Merged

Error handling and logging #714

merged 60 commits into from
Apr 8, 2020

Conversation

bart-degreed
Copy link
Contributor

@bart-degreed bart-degreed commented Apr 7, 2020

This PR is mostly about error handling and logging.

  • Ensured all errors go through an extensibility point (IExceptionHandler), which makes logging and exception handling customizable (see CustomExceptionHandler in tests). DefaultExceptionHandler provides virtual methods to adapt logging level, log message and the conversion from Exception to Error response objects.
  • Converted action results into rich JsonApiException objects and added/updated tests to assert on the returned error objects.
  • Fixed broken model state validation.
  • Fixes around returning response body with NotFound for resources and relationships.
  • Improved selection for which parser handles a query string parameter, allowing for better error messages.
  • Fixes on handling of omitNull/omitDefault query string overrides.
  • Improvements for handling DisableQueryAttribute.
  • Added trace logging on controller/service/repository flow + JSON requests/responses.
  • Fix in handling zero page size; set default page size to nonzero.

Fixes #631
Fixes #689
Fixes #655
Fixes #709
Fixes #638

Bart Koelman added 30 commits April 1, 2020 20:33
…lection of errors, instead of *being* one.

Changed JsonApiException to contain a single error instead of a collection.
…st always inappropriate to set. Note it is intended to indicate on which query string parameter the error applies or on which json path (example: /data/attributes/lastName). These being strings may make users believe they can put custom erorr details in them, which violates the json:api spec. ErrorSource should only be filled from model validation or query string parsing, and that should not be an option that can be disabled.
- All errors are now directed to IExceptionHandler, which translates Exception into Error response and logs at level based on Exception type
- Added example that overrides Error response and changes log level
- Replaced options.DisableErrorStackTraces with IncludeExceptionStackTraceInErrors; no longer static -- this option is used by IExceptionHandler
- Added IAlwaysRunResultFilter to replace NotFound() with NotFound(null) so it hits our output formatter (workaround for dotnet/aspnetcore#16969)
- Fixes #655: throw instead of writing to ModelState if input invalid
- Added test that uses [ApiController], which translates ActionResults into ProblemDetails
…nslated into a database constraint. This makes it impossible to toggle per test. So using regex constraint instead.
…r errors.

Replaced class-name-to-query-string-parameter-name convention with pluggable logic. Parsers now have a CanParse phase that indicates whether the service supports parsing the parameter. Their IsEnabled method checks if the query parameter is blocked by a controller attribute (which now supports passing multiple parameters in a comma-separated list). Finally, support has been added for omitNull/omitDefault to be blocked on a controller. And instead of silently ignoring, a HTTP 400 is returned passing omitNull/omitDefault from query string when that is not enabled.
…ated custom exception, updated Errors to match with json:api spec and added error details validation to tests. Fixed missing lowerbound check on negative page numbers. Tweaks in query parameter name checks, to reduce chance of collisions.
…at is thrown when the operating system denies access because of...."

Adding this as InnerException is not only wrong (this is not an OS error), but it adds no extra info because there is no nested call stack. If you want to catch this, create a custom exception that derives fromJsonApiException instead.
@bart-degreed bart-degreed requested a review from maurei April 7, 2020 13:38
Bart Koelman added 4 commits April 8, 2020 12:09
…cause they hide potential usages of property names instead of resource names, which only works with the default camel-case convention but breaks on kebab casing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants