Bug 553695 - EditingDomainServices throws an NPE from getPropertyDescriptorChoiceOfValues
Summary: EditingDomainServices throws an NPE from getPropertyDescriptorChoiceOfValues
Status: CLOSED FIXED
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 6.1.0   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: 6.3.1   Edit
Assignee: Pierre-Charles David CLA
QA Contact: Laurent Redor CLA
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-12-03 07:53 EST by Pavel Vlasov CLA
Modified: 2020-06-19 10:22 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Vlasov CLA 2019-12-03 07:53:03 EST
There is no null check when an ArrayList is constructed from the choice of values. As a result an NPE is thrown and it becomes impossible to customize a property view by using a select if there is a choice of values, I had to resort to a Java service which catches the NPE and returns null.

Code (org.eclipse.sirius.ext.emf.edit.EditingDomainService line 549):

    public List<?> getPropertyDescriptorChoiceOfValues(EObject self, String featureName) {
        IItemPropertyDescriptor desc = getPropertyDescriptorForFeature(self, featureName);
        if (desc != null) {
            return new ArrayList<>(desc.getChoiceOfValues(self)); // The culprit line
        } else {
            return null;
        }
    }
 
Proposed fix:

    public List<?> getPropertyDescriptorChoiceOfValues(EObject self, String featureName) {
        IItemPropertyDescriptor desc = getPropertyDescriptorForFeature(self, featureName);
        if (desc != null) {
            Collection<Object> choices = desc.getChoiceOfValues(self);
            return choices == null ? null : new ArrayList<>(choices);
        } else {
            return null;
        }
    }
Comment 1 Pierre-Charles David CLA 2019-12-03 08:47:35 EST
Thanks for the bug report. This looks like a no-brainer, we'll try to include this in the next maintenance release (for which we do not have a date yet).

I'd rather return an empty lis than null when getChoiceOfValues() returns null (which propagates the risk of NPE to the callers). Do you see a reason to explicitly distinguish between null and an empty list here?
Comment 2 Pavel Vlasov CLA 2019-12-03 10:19:08 EST
Hello,

Null and empty list have different semantics in EMF.Edit. Null means no constraints - any value - text field. Empty list means no choices - default value.

Therefore, it shall be null. There isn't much risk in returning null, IMO, as there is already an execution path that returns null - the last return if desc is null.
Comment 3 Eclipse Genie CLA 2020-01-20 04:10:08 EST
New Gerrit change created: https://git.eclipse.org/r/156165
Comment 4 Pierre-Charles David CLA 2020-01-20 04:10:38 EST
Sorry for the delay.

You're right of course. https://git.eclipse.org/r/156165 should fix this.
Comment 5 Pierre-Charles David CLA 2020-02-18 09:47:56 EST
Fixed by 495ec1d8b15ff28e904370e8a939311d05a9245c.
Comment 8 Pierre-Charles David CLA 2020-06-19 10:22:14 EDT
Available in Sirius 6.3.1 (part of Eclipse 2020-06). See https://wiki.eclipse.org/Sirius/6.3.1 for details on the release.