Am 16.02.10 07:18, schrieb Stefan Liebig:
My
personal favorite is a), it is:
- explicit
- safe
+1
A
first look at the usage of the getXXXSetting without default parameter
shows that sometimes a default will be applied by the calling code
sometimes not causing an NPE if not defined.
So, a question arises: Is it an error if a setting has not been
defined?
if a setting has not been defined there should always be a fallback to
a default
from my POV its not an error, but I would log a warning
ekke
Tschüß,
Stefan
On 15.02.2010 23:37, Christian Campo wrote:
there is also
c) that all getXXXSetting method HAVE to return a non null value, so
changing the contract. that would make life easier vor teh components
using LnF.
@Thorsten?
christian
Am 15.02.2010 um 21:30 schrieb Elias Volanakis:
Hi everybody,
here's something to discuss:
I realized that we a dozen or more potential null-pointer-exceptions
waiting to happen, because of the way we use the RienaDefaultLnf:
Example 1:
boolean on =
lnf.getBooleanSetting(LnfKeyConstants.DISABLED_MARKER_ADVANCED);
Example 2:
shellRenderer.setCloseable(lnf.getBooleanSetting(LnfKeyConstants.TITLELESS_SHELL_SHOW_CLOSE));
Example 3:
private int getSwitchterHeight() {
int margin =
LnfManager.getLnf().getIntegerSetting(LnfKeyConstants.SUB_APPLICATION_SWITCHER_HEIGHT);
return margin;
}
The problem here is that the getXXXSetting methods may return null,
which causes an NPE if used together with auto-boxing (Integer-to-int,
Boolean-to-boolean).
(a) My favorite approach would be to deprecate/remove these methods
and use a second variant that always needs a default value:
lnf.getBooleanSetting(KEY, false); lnf.getIntegerSetting(KEY, 0). We
already have these methods :-)
(b) If we don't go for (a), we have to at least go over all places in
the code and make sure we handle a null return value. However this
will not prevent it from re-happening later.
Looking forward to feedback,
Elias.
--
Elias Volanakis | Technical Lead | http://eclipsesource.com
elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: 069 / 27 22 18 0
fax: 069 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-------------------------------------------------------------
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
--
ekke (ekkehard gentz)
independent software-architect
senior erp-consultant
eclipse | osgi | equinox | mdsd | oaw | emf |
uml
max-josefs-platz 30, D-83022 rosenheim, germany
mailto:ekke@xxxxxxxxxxxxxxxx
homepage (de): http://gentz-software.de
blog (en): http://ekkes-corner.org
twitter: @ekkescorner
skype: ekkes-corner
Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID:
DE189929490
|
