Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [riena-dev] RienaDefaultLnf considered harmful ?

I also prefer version a)
with some adjustment:
- The methods with the default parameter should be log (warning!?) if no LnF value exists
- I think we also need methods with default parameters for getFont, getColor, getRenderer etc.

The usage of these methods with default parameter will also help to write some unit tests more easily. For example in some tests it is necessary to set a correct LnF to avoid null-pointer-exceptions.

Greetings

Thorsten



-----Ursprüngliche Nachricht-----
Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Stefan Liebig
Gesendet: Dienstag, 16. Februar 2010 07:19
An: Riena Developers list
Betreff: Re: [riena-dev] RienaDefaultLnf considered harmful ?

My personal favorite is a), it is:
- explicit
- safe

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?

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

Back to the top