OpenRefine / OpenRefine/OpenRefine

Replace all Throwable.printStackTrace() with error reporting or logging

Open
#5,366 10 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

maintainability Type: Bug
Dominant language
Java
Stars
12k
Forks
2.2k
Avg merge
1d 14h
Merged PRs (30d)
27

Description

In investigating #5354, I realized that this is just the tip of the iceberg and there are a large number of places (~100) in the code where a naked e.printStackTrace() call is used. Some of the particularly bad cases represent places where error information should be returned to the user, but is instead dumped to stdout (which is usually hidden). These need to be fixed to provide proper error reporting back to the client. The remainder should be converted to using logging so that they can be turned on/off, routed to log collectors, reformatted, etc.

By default they probably just need to replace with something like LOGGER.error("<Meaningful error message here>", e)

Note that there are also some calls to printStackTrace(PrintWriter s) which is used to get a formatted stack trace to forward to the front end. These are probably fine as is.

There are also examples of empty catch blocks or ones which say something like "TODO: How do we report this error" which can't be found with a simple grep.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with a repository-wide search for Throwable.printStackTrace(), e.printStackTrace(), printStackTrace(PrintWriter), empty catch blocks, and TODO error-reporting notes. Review each occurrence to determine whether the error belongs in client-facing reporting or logging; preserve formatted stack traces forwarded to the frontend. Done means the applicable naked calls are replaced and the remaining error-handling gaps are addressed.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend, observability
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.