Uploaded image for project: 'Apache Fineract'
  1. Apache Fineract
  2. FINERACT-932

Parent Issue for Error Logs seeing during "normal" usage (e.g. on fineract.dev)



    • Improvement
    • Status: Open
    • Blocker
    • Resolution: Unresolved
    • 1.4.0
    • 3.0.0
    • None
    • None


      I'm seeing a number of exceptions in the logs of 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.


        Issue Links



              vorburger Michael Vorburger
              vorburger Michael Vorburger
              0 Vote for this issue
              2 Start watching this issue