Consider generalizing Errors so that it also works for more constrained throwers
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- java
- Domain
- backend-api-design
Research direction
The issue names the existing Errors abstraction but no files or tests. Start by locating Errors and examining how it wraps checked and unchecked throwables; the work is done when a generalized wrapper accepts a designated checked exception type while allowing other unchecked exceptions to propagate unchanged.
Written by the indexing model from the issue text.
Description
Unless I missed something, Errors currently is used to wrap all throwables. It would be useful to be able to use Errors (or a generalized version of it, say, SpecificErrors) to wrap interfaces which throw only one checked exception, for example, IOException. Thus, SpecificErrors would be a generic type, with a type parameter <E> which designates the kind of throwable to be wrapped. Any other unchecked exception thrown by the wrappers created by SpecificErrors would be left alone and thrown as-is.
- Dominant language
- Java
- Stars
- 292
- Forks
- 26
- PR merge metrics
- No merged PRs in 30d
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.
More from diffplug/durian
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
area/frontend
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
opensearch-project/k-NN#3597 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100