[
https://issues.apache.org/jira/browse/FINERACT-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113039#comment-17113039
]
Michael Vorburger commented on FINERACT-932:
--------------------------------------------
BTW for anyone interested in this topic, I use
[https://cloud.google.com/error-reporting] to get notified about all linked
issues.
> 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
> Priority: Major
>
> 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.3.4#803005)
