[
https://issues.apache.org/jira/browse/FINERACT-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated FINERACT-932:
---------------------------------------
Description:
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 the
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.
was:
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 the
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.
> 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 the 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)
