Crash when reusing from unsaved aspect

Issue #404 resolved
Matthias Schoettle created an issue

The following exception occurs when reusing a concern from an unsaved aspect (due to the recent changes/improvements) when selecting the concern:

java.lang.NullPointerException
    at ca.mcgill.sel.ram.ui.components.browser.CoreFileBrowser$1.fileSelected(CoreFileBrowser.java:54)
    at ca.mcgill.sel.ram.ui.components.browser.RamFileBrowser.openFile(RamFileBrowser.java:822)
    at ca.mcgill.sel.ram.ui.components.browser.RamFileBrowser.fileItemDoubleTapped(RamFileBrowser.java:659)
    at ca.mcgill.sel.ram.ui.components.browser.RamFileBrowser.access$1(RamFileBrowser.java:648)
    at ca.mcgill.sel.ram.ui.components.browser.RamFileBrowser$FileItem$TapHandler.processTapEvent(RamFileBrowser.java:1004)

Comments (8)

  1. Matthias Schoettle reporter

    I don't think that's necessary. The concern is already saved, that should be enough.

  2. Cécile Camillieri

    Sorry to bump.

    The changes seem to cause issues on Windows-based systems (I think only Windows).

    In COREModelUtil.getLocalConcern(..), reusedConcernURI.path() returns null. From what I understand it's because on Windows URIs start with c:\Users.. and not \c\Users... and emf's URI doesn't recognize this as a hierarchical URI and so path() returns null.

    I made a quick fix on my branch Weaver-Reexpose (changes made both in core and ram repo). I'm not sure if it's the best way to do it and if it works on Mac, that's why I did not push directly on master.

    Commits:

  3. Matthias Schoettle reporter

    No problem.

    If I understand this right, instead of createURI you use createFileURI and instead of toString() you use toFileString()?

    Seems legit to me since we want to use a file anyway.

  4. Log in to comment