[DivideTransformationProfile] generating NumberFormatException

[clinique]

Under certain circumstancies I get this exception at startup :

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.

[J-N-K]

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.

[clinique]

Have you filed a bug in openhab-core ? Do you want me to do it ?

[J-N-K]

No, I didn't file a bug, would be great if you could do that. I can put that on my list for things that need fixing.

[clinique]

Done

[J-N-K]

Can you reproduce this? Would you be willing to test a debug version that logs input/output so we can find out how this "0E+1" value is created?

[clinique]

Yes, I can reproduce it. Here's the definition of the channel / item link :

I have this error when the binding comes online (usually at OH startup) - and I suspect that the channel sets it's value to 0.

[clinique]

Correct. The channel value is set to 0 when the exception triggers :

2022-03-29 10:49:00.674 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'SynopTRAPPES_Octa' received command REFRESH
2022-03-29 10:49:00.742 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SynopTRAPPES_Octa' changed from 12 to 0

==> /var/log/openhab/openhab.log <==
2022-03-29 10:49:00.735 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.synopanalyzer.internal.handler.SynopAnalyzerHandler@76c740a5': Invalid BigDecimal value: 0E+1
java.lang.NumberFormatException: Invalid BigDecimal value: 0E+1
    at org.openhab.core.library.types.DecimalType.<init>(DecimalType.java:102) ~[bundleFile:?]
    at org.openhab.core.library.types.DecimalType.<init>(DecimalType.java:86) ~[bundleFile:?]
    at org.openhab.core.library.types.DecimalType.valueOf(DecimalType.java:125) ~[bundleFile:?]
    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) ~[?:?]

[J-N-K]

I can reproduce it now, new BigDecimal("0").divide(new BigDecimal("8")) returns 0E+1. I still believe this is a bug in core, but I don't think the discussion will lead to anything.

[clinique]

Agree, if this is a valid BigDecimal and DecimalType accepts BigDecimal I do not get why an exception could exist for this given value.