cactoos: Should we stop using checked exceptions?
I noticed the pain it can be to use all the interfaces like Text or Scalar that throws Exception.
You have to wrap them most of the time in IoCheckedXXX or UncheckedText.
In the end it feels like all this gymnastic is defeating the whole purpose of having cached exceptions. And the only places where we catches exceptions in cactoos are… where we catch the superclass Exception!
I just read this: https://pragmaticobjects.com/chapters/001_checked_exceptions.html and there is in the comments a discussion about cactoos.
I wonder if we should not:
- introduce our own
UncheckedException extends RuntimeException - use it everywhere it is necessary to re-throw a checked exception.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 3
- Comments: 18 (5 by maintainers)
Commits related to this issue
- For #944 - removed `throws Exception` from `Text#asString` — committed to pinaf/cactoos by pinaf 6 years ago
- For #944 - qulice — committed to pinaf/cactoos by pinaf 6 years ago
- For #944 - removed `UncheckedText` uses - can't remove the class without breaking cactoos-matchers — committed to pinaf/cactoos by pinaf 6 years ago
@victornoel the main purpose I wrote this post is to prove that there is nothing good in checked exceptions for “Elegant Objects” approach. And Cactoos IMO is very representative example of that. These
UncheckedScalarstuff and similar classes which wrap checked exceptions to unchecked is just a burden, and a cheat for overriding the principles.So, I’d go further and just:
throws Exceptionsfrom interfaces.Checked/Uncheckedin their names.It would:
@fabriciofx @skapral @llorllale @yegor256 some more questions that are bothering me on that matter: if we remove the exception, shouldn’t we switch to using java.lang.Function, BiFunction, Consumer, BiConsumer and Supplier to replace Func, BiFunc, Proc, BiProc and Scalar?
@victornoel I think we need return to this discussion and I vote to remove all exceptions from interfaces. It will be drive to a simpler design and more composable object system.