Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Immutables
Annotation processor to create immutable objects and builders. Feels like Guava's immutable collections but for regular value objects. JSON, Jackson, Gson, JAX-RS integrations included
-
noexception
Java library for handling exceptions in concise, unified, and architecturally clean way.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I think this project shows how trivial it is to convert checked exception errors to compiler warnings.
https://github.com/rogerkeays/unchecked/blob/fd15f5f6e4fa7c4...
No need to change the type hierarchy. Just make it a compiler option.
Most other languages agree that checked exceptions are not good by not having them.
As for alternatives, Try/Result and similar monads have decent adoption even in Java, but personally I quite like the Kotlin philosophy [1] to not have generic error containers and either use runtime exceptions or make failures of the return type.
[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...
This is every Lombok lover's favorite strawman argument I've run into.
I've been coding in Java professionally for ~20 years. I can count with zero hands the number of times I've been burned by a getter or setter getting changed into something surprising.
If you really need auto-generated getters/setters/builders - Immutables [1] is a library that does it using bog standard annotation processing rules that don't require hacking your build process.
[1] https://github.com/immutables/immutables
Putting aside the discussions about the necessity of checked exceptions (to which I feel unqualified to express my opinion), I believe the approach used by the OP article is not the best one:
- It requires modifying compiler arguments and putting some file in the local classpath! That's really not Java-ic. Is it?
- It is not transparent in the code. You cannot infer by looking at the source code that something has changed.
Since some time ago I use the NoException library[0] in my Java projects which achieves the same goal but without the above-mentioned issues. It can also be used to mimic Scala's Try construct.
[0] https://github.com/robertvazan/noexception
This is from my original solution to the problem:https://github.com/rogerkeays/jamaica-core/blob/0cc98b114998....