From 560ded50127b12bd8168f8ae2bada47253f15bc8 Mon Sep 17 00:00:00 2001
From: Reinier Zwitserloot
- Current status: positive - Currently we feel this feature may move out of experimental status with no or minor changes soon.
+ Current status: neutral - Currently we feel this feature may not move out of experimental status without changes.
@f.experimental>
<@f.overview>
diff --git a/website/templates/features/experimental/StandardException.html b/website/templates/features/experimental/StandardException.html
index 1484154d..c7fc40fe 100644
--- a/website/templates/features/experimental/StandardException.html
+++ b/website/templates/features/experimental/StandardException.html
@@ -48,6 +48,8 @@
There is a very slight functional difference: Normally, invoking lombok.config
entry of lombok.fieldDefaults.defaultPrivate = true
(or, analogously, defaultFinal
) is enough to modify every source file that is affected by that configuration, even if said source file has absolutely no trace whatsoever of lombok anything inside it. We're not quite sure if this is a good idea. Our current point of view is that this is too much magic, and there is an alternative plan: meta-annotations. Until at least the meta-annotations idea has been explored and discarded, this feature will not be leaving experimental in its current state. Most likely, if it ever does, the lombok.FieldDefaults
annotation will be required, though, you may set it via the to be built meta-annotation.
new SomeException(message, null)
will initialize
the cause to be no cause, and this cannot be later changed by invoking initCause
. However, lombok's
standard exceptions do let you overwrite an explicit no-cause with initCause
later.
+
+ A second slight functional difference: Normally, invoking new SomeException(cause)
, if implemented as super(cause);
, will set the message to be equal to the message of the cause. However, lombok does not do this - it leaves the exception as having no message at all. We think inheriting the message is fundamentally wrong - messages are not guaranteed to be sensible in the absence of the context of the exception-type. The cause ought to be listed anywhere where it is relevant; if you are using messages as direct user feedback (which is rare, in the java community), @StandardException
can't really help you anyway; the infrastructure of e.g. getLocalizedMessage()
is too complicated.