Handle errors internally and show them via the API #25

Merged
paul merged 3 commits from handle-errors into main 2022-06-06 16:49:03 +02:00

3 Commits

Author SHA1 Message Date
Paul van Tilburg 014ca5a151
Handle errors on the API side
* The map endpoints return an HTTP 404 error in case of unknown or
  out-of-bound locations
* The forecast endpoint with an address returns an HTTP 404 with error
  JSON in case geocoding fails
* The forecast endpoints return the errors per metric in the `errors`
  field of the forecast
* Implement `Display` for `Metric`
* Use a `BTreeMap` to have an ordered `errors` field/object
* Also log the errors to the console
* Update the tests
* Document the errors that can occur
2022-06-06 16:46:52 +02:00
Paul van Tilburg 8a2a6d769d
Log errors of the map refresher task separately 2022-06-06 15:38:38 +02:00
Paul van Tilburg 69ef08002c
Introduce error types, switch to Results everywhere
* Add dependency on the `thiserror` crate
* Add a global `Error` type, but also `maps::Error` and
  `providers::combined::MergeError` for convenience
* Add matching `Result` types that default to the respective `Error`
  type
* Refactor code to yield all kinds of error variants
* Add FIXMEs where library errors still need to be handled
* Remove documentation that explained why `None` was returned, this is
  captured in the error now
2022-06-06 15:37:54 +02:00