Fix unnecessary exception thrown in Symbol widget

[rjwills28]

We recently came across a warning relating to a macro not being full resolved in the 'name' property.

WARNING [org.csstudio.display.builder.model] Widget '$(TEST)' (symbol) 'name' is not fully resolved: '$(TEST)'

We tracked this back and found it was coming from a Symbol widget, which had a macro in the 'name' property. We found that when we had more than 2 symbols defined for this widget, then we got this warning and indeed, the macro in the name does not get replaced. If we have 2 or fewer symbols then it works correctly and there is no warning.

In the case of >2 symbols, I found that the 'name' property is being evaluated before the screen macros have been expanded and hence the warning.

I dug a little deeper and found that during construction, the symbol widget allows 'index out of bound' exceptions to be thrown and just catches these to ignore them. Indeed, there is a comment in the code to say that this
will happen if there are more than 2 symbols:

phoebus/app/display/model/src/main/java/org/csstudio/display/builder/model/widgets/SymbolWidget.java

Line 106 in 59ebd24

// It is expected when a widget with more than 2 symbols is parsed

From what I read, throwing exceptions in Java can be relatively slow as the JVM has to construct the stack trace. It may also be that this suspends the execution of this thread and allows another one to run. Either way, I found that allowing it to throw the exception delays the expansion of the macros and hence allows for the 'name' property to be evaluated before the expansion.

I was able to fix this by simply updating the if statement to ensure that we do not trigger an 'index out of bounds' exception. There is then no need for the try-catch statement.

Attached is a simple BOB file example to reproduce the issue: symbolWidgetMacroExample.bob.txt
Start with 3 symbols defined and you will see the warning. Then reduce to 2 and there is no warning. Applying my fix will remove the issue altogether.

I will note that this fixes the issue but hides what might be a race condition happening somewhere that allows the evaluation of widget properties before the DisplayModel runs the macro expansion.

Checklist

• Testing:

  • The feature has automated tests
  • Tests were run
  • If not, explain how you tested your changes

• Documentation:

  • The feature is documented
  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant
    • Added an entry when adding a new feature

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud