Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] NPEs from assumption about Notifications' features

Hello,

The best way to deal with this is to test object identity:

    if (… notification.getFeature() == UMLPackage…. …)

or

    if (… notification.getFeature() == NotationPackage…. …)

I agree with your reasoning about custom equals, but still believe that the best way to deal with it, (as we normally do with string equality tests) is to use pattern
        <constant>.equals(<variable>)
instead of
        <variable>.equals(<constant>)

The UMLPackage.xxx() does not 100% qualify as a "constant" but anyway it is known to be not null, and I believe that using a method call (where you can set breakpoint for just one example) is better comparing to direct comparison.

Regards,
Michael



On Wed, Mar 11, 2015 at 9:58 PM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
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



_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev



--

Michael "Borlander" Golubev
Eclipse Committer (GMF, UML2Tools)
at Montages Think Tank, 
Prague, Czech Republic
1165/1 Dvorecka, 14700, Prague-4 Podoli

tek: +420 602 483 463


Back to the top