OpenRefine / OpenRefine/OpenRefine
Replace all Throwable.printStackTrace() with error reporting or logging
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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