General Guideline
| 1 | It is up to the consumer of the java API if they want to log the exception or not. |
| 2 | In the REST API when we catch an exception we should log it as we lose a lot of information when we convert it into a HTTP response code. |
| 3 | For business exceptions we will use error level but we will add configuration so that it is not written to the console by default. |
| 4 | You should log the original exception if it provides more information. |
| 5 | For business exceptions we will use error level but we will add configuration so that it is not written to the console by default. |
Logging Examples Specific to CPS
| # | Scenario | Logging level | Decision on how/where to log |
|---|---|---|---|
| 1 | If the user tries to add an anchor with no dataspace we will log "Dataspace does not exist". | This will be logged in the place it is handled. | |
| 2 | Where exactly to log error, at source or a common central place?
|
Summary of each logging level
Log Level | Importance |
|---|---|
| Fatal | One or more key business functionalities are not working and the whole system doesn’t fulfill the business functionalities. |
| Error | One or more functionalities are not working, preventing some functionalities from working correctly. |
| Warn | Unexpected behavior happened inside the application, but it is continuing its work and the key business features are operating as expected. |
| Info | An event happened, the event is purely informative and can be ignored during normal operations. |
| Debug | A log level used for events considered to be useful during software debugging when more granular information is needed. |
| Trace | A log level describing events showing step by step execution of your code that can be ignored during the standard operation, but may be useful during extended debugging sessions. |