DecimalType throwing error in constructor for value 0E+1

[clinique]

Under certain circumstancies I get this exception at startup :
Here's the error log :

2022-03-23 14:52:15.684 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NumberFormatException: Invalid BigDecimal value: 0E+1
	at org.openhab.core.library.types.DecimalType.<init>(DecimalType.java:102) ~[?:?]
	at org.openhab.core.library.types.DecimalType.<init>(DecimalType.java:86) ~[?:?]
	at org.openhab.core.library.types.DecimalType.valueOf(DecimalType.java:125) ~[?:?]
	at org.smarthomej.transform.math.internal.profiles.AbstractMathTransformationProfile.transformState(AbstractMathTransformationProfile.java:95) ~[?:?]
	at org.smarthomej.transform.math.internal.profiles.DivideTransformationProfile.onStateUpdateFromHandler(DivideTransformationProfile.java:70) ~[?:?]
	at org.openhab.core.thing.internal.CommunicationManager.lambda$11(CommunicationManager.java:534) ~[?:?]
	at org.openhab.core.thing.internal.CommunicationManager.lambda$13(CommunicationManager.java:554) ~[?:?]
	at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
	at org.openhab.core.thing.internal.CommunicationManager.handleCallFromHandler(CommunicationManager.java:550) ~[?:?]
	at org.openhab.core.thing.internal.CommunicationManager.stateUpdated(CommunicationManager.java:532) ~[?:?]
	at org.openhab.core.thing.internal.ThingManagerImpl$1.stateUpdated(ThingManagerImpl.java:176) ~[?:?]
	at org.openhab.core.thing.binding.BaseThingHandler.updateState(BaseThingHandler.java:268) ~[?:?]
	at org.openhab.core.thing.binding.BaseThingHandler.updateState(BaseThingHandler.java:287) ~[?:?]
	at org.openhab.binding.synopanalyzer.internal.handler.SynopAnalyzerHandler.lambda$4(SynopAnalyzerHandler.java:161) ~[?:?]
	at java.util.ArrayList.forEach(ArrayList.java:1541) ~[?:?]
	at java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085) ~[?:?]
	at org.openhab.binding.synopanalyzer.internal.handler.SynopAnalyzerHandler.lambda$3(SynopAnalyzerHandler.java:158) ~[?:?]
	at java.util.Optional.ifPresent(Optional.java:183) ~[?:?]
	at org.openhab.binding.synopanalyzer.internal.handler.SynopAnalyzerHandler.updateSynopChannels(SynopAnalyzerHandler.java:157) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

I think it maybe by channel being UNDEF or NULL but not sure.

At first approach, I thought it would be generated by DivideTransformationProfile (issue created here) but after looking at it @J-N-K arrived to the conclusion it was located in DecimalType.
This is a bug in the DecimalType parsing code in openhab-core. new BigDecimal("0E+1") returns a valid value, however the parsing code throws an exception because the parsing stops after the 0. The returned value is nevertheless valid.

[wborn]

IIRC the 0E+1 variant is no longer supported by the UoM library whereas I think 0E1 still is. That's why I also removed this variant from the QuantyType tests in #2319. So it might cause different issues if one type starts supporting this variant again while another one doesn't. 😉

[clinique]

Does this mean that DivideTransformationProfile is at the end the culprit ?

[J-N-K]

The question is where such a value comes from if it is considered illegal in openHAB.

[J-N-K]

A workaround has been added in the solution used and we can't fix the UoM library. It is inconsistent to support it for DecimalType but not for QuantityType.