search

NOAA-OWP / wres

Code and scripts for the Water Resources Evaluation Service
Other
2 stars 1 forks source link

As a developer, I want the application to exit with a specialized code if it fails due to no fault of the user or application #190

Open epag opened 4 weeks ago

epag commented 4 weeks ago

Author Name: Chris (Chris) Original Redmine Issue: 54181, https://vlab.noaa.gov/redmine/issues/54181 Original Date: 2018-08-17

If an external service (such as USGS) encounters some issue and we are effected (such as USGS returning a 500 code), we still need to stop the application, but an exit code differing from a general application failure would make automating the WRES far easier to automate. For instance, we can determine a run of the application failed if it returns something other than 0. The general failure code (if I recall correctly) is -1. That does not give enough information. If we offer another code for service failures (such as that USGS 502 situation), we can determine that the app didn't necessarily fail and that non-service reliant automated runs may continue.

It might also be prudent to offer different error codes for different situations, such as database interaction failures (malformed queries, connection issues, etc), invalid project configurations, insufficient data, no successful evaluations, etc.

Related issue(s): #180 Redmine related issue(s): 41467, 50810

epag commented 4 weeks ago

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2018-09-26T16:27:01Z

Agree that callers should be able to distinguish (at least) the general categories of errors.

In the simplest form, InternalWresException could exit 5, UserInputException could exit 4, and anything else could exit 3 (which would indicate a programming error or a serious Error).

epag commented 4 weeks ago

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2018-09-26T17:53:42Z

More in the spirit of the original post, agree that another category could be created for unavailability of upstream dependencies. I think there's a ticket somewhere for that, will relate it.

epag commented 4 weeks ago

Original Redmine Comment Author Name: Jesse (Jesse) Original Date: 2022-05-09T20:13:48Z

It looks like this was implemented in commit:82b660c292cc098ac8896cbd3c4ceb1850fd1e65 over a year ago, at least for core WRES. At the COWRES level, the reported status is still dichotomous for found jobs that exit: @COMPLETED_REPORTED_SUCCESS@ or @COMPLETED_REPORTED_FAILURE@.