Java Exception when trying to open the preferences with missing custom theme

[AtrusRiven]

JabRef 5.2--2020-12-09--d1fb9e2

When trying to open the preferences dialogue a java exception occurs:
Cannot load org.jabref.gui.preferences.preferencesdialog

[AtrusRiven]

Could solve the problem: Obviously, a broken path of the custom theme CSS (due to a change of the name of the folder containing the custom theme CSS) caused the exception. After reinstalling the release version, having been able to change all paths in this version (this version didn't have the custom theme feature) and reinstalling the current master branch version, all works again. Maybe a better handling of broken paths could prevent such exceptions?

[calixtus]

We'll will take a look at this. Unfortunately, I believe this problem may sit deeper in the javafx library, since the css' are handled there... We will see.

[docrjp]

I'm having a look at this as a first contribution attempt.

I was able to reproduce the issue as reported:

1. Made up a nonsense path in the custom theme text box of the preferences dialog.
2. Restarted app successfully.
3. Clicked again on menu Options -> Preferences
4. Dialog box pops up with uncaught exception in JavaFX application thread including stack trace.

Observation: the bad CSS path does not affect the application overall. Only previews are impacted (and the preference dialog has a preview tab).

After some code inspection and debugging, I can see the reason for this. JabRefPreferences has logic to check if the custom css file exists, and store it as a URL if it does, otherwise no URL is stored in the Optional value. This is what the application uses in general. However, the preview viewer bypasses this logic, and directly parses the path, which is exposed by a getter.

That getter is also used for saving the settings, so I think it should stay.

I successfully tried out a tentative fix: adding a second getter that exposes the URL as processed by JabRefPreferences. Only if this URL is set, will the preview viewer use it. However, I would like to take a bit more time to consider if there is a better solution, and get my head around the contribution guidelines, before I submit a PR.

One final thought. I think that the preferences tab should show a validation hint when the file is missing. It wouldn't have prevented this case, because as I understand it, the path was correct at the time of configuration and changed only later. Still, I think it would help the user when their CSS file is moved or mistyped. I am happy to create a separate issue for this and give it a go; I don't think it should block the fix of the uncaught exception.

[calixtus]

Hi @docrjp , thank you very much for diving into the code and creating a fix. Can you please create a pull request with your changes, so it's somewhat easier to discuss them?