[
https://issues.apache.org/jira/browse/FINERACT-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy updated FINERACT-932:
--------------------------------
Fix Version/s: (was: 3.0.0)
> Parent Issue for Error Logs seeing during "normal" usage (e.g. on
> fineract.dev)
> -------------------------------------------------------------------------------
>
> Key: FINERACT-932
> URL: https://issues.apache.org/jira/browse/FINERACT-932
> Project: Apache Fineract
> Issue Type: Improvement
> Affects Versions: 1.4.0
> Reporter: Michael Vorburger
> Assignee: Michael Vorburger
> Priority: Blocker
>
> I'm seeing a number of exceptions in the logs of
> [https://www.fineract.dev|https://www.fineract.dev/], and at least some if
> not most of them, to me, seem like things that probably should not be logged
> as errors.
> IMHO, a log.error() should only be used to indicate something "broken" (e.g.
> can't connect to a database), but not, typically, for something like a
> missing field problem in an incoming JSON? That's "normal", and already
> signaled to th e client through an expected response. An "operator" can't
> typically "do something" about those kinds of errors.
> We can also think of some special cases, e.g. the log.error we currently for
> FINERACT-726, which may be useful to help people more easily see that
> widespread problem, during transitioning. But perhaps log warn or even info
> instead of error would be more appropriate than error for such things?
> Perhaps what I'm outlining here should be documented on the README in a
> (succinct) "Log Policy" kind of section?
> I'll create dedicated linked issues for each such exception I'm seeing, for
> analysis by others interested.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
