Hi, Team,
I see reams of NullPointerExceptions in the workspace logs of run-time workbenches and JUnit test executions that all stem from the same pattern that is repeated in many places in the Papyrus code:
if (… notification.getFeature().equals(UMLPackage….) …)
or
if (… notification.getFeature().equals(NotationPackage….) …)
where often the notification’s feature is, in fact, null. These are the most common patterns; there are others.
This pattern is suspect because the Notification API contract does not guarantee a non-null feature. In fact, every notification from a Resource or a ResourceSet has a null feature because these are not modelled types.
Moreover, Papyrus has components that inject additional notifications into objects, such as notifications for application/unapplication of stereotypes. These also often do not report any feature. So, although in most EMF-based applications one would expect Notifications from EObjects always to have features, in Papyrus this is not the case.
The best way to deal with this is to test object identity:
if (… notification.getFeature() == UMLPackage…. …)
or
if (… notification.getFeature() == NotationPackage…. …)
because EObjects in general, and the elements of Ecore models especially, don’t implement a custom equals(…) so they just test object identity anyways.
So, wherever you see NPEs happening in label edit-policies and other places, and you happen to have an opportunity to clean up this pattern, please do! Solid-state storage devices everywhere will thank you for saving them untold rewrite cycles.
Thanks,
Christian
