PED named key does not honor case when retried from Feature object

[alexbk66]

We almost never use exceptions. If there is an exception, than we overlooked something and it is not safe anymore to use the application. Hence, we let the application crash and have it restarted automatically (I work in the medical industry). We do have a high code coverage and automated MTBF tests, so we know crashes take seldom place.

We could have a discussion, but probably not in this thread. But quickly about exceptions - sometimes exceptions are normal, often in communication apps (i.e. TCP/IP) or database apps... And often you can't let app just crash - i.e. in real time control apps or multi-user apps. I work on CSIRO on many projects for Australian Synchrotron or solar thermal power stations.

[kriz83]

I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.

Personally (and in our entire organisation), we prefer functions that have 1 or 2 return paths. If you have a multitude of conditions to check, than probably the function could/should be splitted up.

We almost never use exceptions. If there is an exception, than we overlooked something and it is not safe anymore to use the application. Hence, we let the application crash and have it restarted automatically (I work in the medical industry). We do have a high code coverage and automated MTBF tests, so we know crashes take seldom place.

[alexbk66]

I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.

No problem The reason been - we just had similar discussion at work....

[racerfern]

I know nothing about coding in whatever language this is. My "programming" experience dates back to Fortran WAT V. However, I'm enjoying this conversation more than any other on this forum. Thanks for the lessons.

[alexbk66]

I would get rid of all the checks, since at the end we'are doing a catch all anyways :-(

Otherwise:

if ( (obj != null) && (!String.IsNullOrEmpty(key?.trim()) )

Avoiding exceptions is always a good taste.
And if you have many checks - can you imagine how long the line would be? And debugging this will be a nightmare - how do you find which check fails?
Sorry for drugging this off-topic...
[EDIT] But what I don't get - why there's two try/catch blocks?

[kriz83]

I would get rid of all the checks, since at the end we'are doing a catch all anyways :-(

Otherwise:

if ( (obj != null) && (!String.IsNullOrEmpty(key?.trim()) )

The point I was trying to make here is that the cyclomatic complexity of this little function is quite high, but that is irrelevant to the context of this issue :-)

[alexbk66]

One note -

If String.IsNullOrEmpty(Key.Trim)

- will fail if Key is null. Should be

If String.IsNullOrEmpty(Key?.Trim)

[alexbk66]

Never seen a function with that many different return paths.

I actually prefer the style above - if any condition not satisfied - return False. Then do the stuff and return True. Any exception - return False.

Do you believe this looks better?

[kriz83]

Reviving a 5 month old thread? Just fix the issue plz ...

Never seen a function with that many different return paths. This is an absolute drama when debugging an application.

Verstuurd vanaf mijn SM-G965F met Tapatalk

[JLDubz]

Can confirm that the HS3 SDK did not support mixed case keys. You can find the source code attached:

        Public Function AddNamed(ByVal Key As String, ByVal Obj As Object) As Boolean
            Try
                If Key Is Nothing Then Return False
                If String.IsNullOrEmpty(Key.Trim) Then Return False
                If Obj Is Nothing Then Return False
                CheckNamed()
                SyncLock Ncol.SyncRoot
                    Try
                        If Ncol.ContainsKey(Key.Trim.ToLower) Then Return False
                        SyncLock Ncol.SyncRoot
                            Ncol.Add(Key.Trim.ToLower, Obj)
                        End SyncLock
                        Return True
                    Catch ex As Exception
                        Return False
                    End Try
                End SyncLock
            Catch ex As Exception
                Return False
            End Try
        End Function

        Public Function AddUnNamed(ByVal Obj As Object) As Integer
            Try
                If Obj Is Nothing Then Return -1
                CheckUnNamed()
                SyncLock UNcol.SyncRoot
                    Return UNcol.Add(Obj)
                End SyncLock
            Catch ex As Exception
                Return -1
            End Try
        End Function

You can see it in this line here: Ncol.Add(Key.Trim.ToLower, Obj)

Will look into ditching this limitation though. I'm updating the documentation to reflect this until we can implement a workaround.

[rmasonjr]

HS3 definitely allowed mixed case PED keys.

[Michael McSharry]

I am porting a HS3 implementation so I do not think it was the case with HS3.

[alexbk66]

I think it was always the case, even in HS3

[rmasonjr]

I switched all my PED to lowercase based on this post. rjh didnt comment, so I assume that is the way it's going to be going forward.

[Michael McSharry]

A PED entry was made with:

Const PEDKEY As String = "PEDkey"
PED.AddNamed(PEDKEY, Join(arrPED, ","))

When observed with Debugger the PED object was as expected named entry with key ""PEDkey"

The feature was updated to contain the PED with:

hs.UpdatePropertyByRef(iTopRef, HomeSeer.PluginSdk.Devices.EProperty.PlugExtraData, PED)

Subsequently a new PED object was retrieved from the Feature:

Dim PED As HomeSeer.PluginSdk.Devices.PlugExtraData = hs.GetPropertyByRef(iTopRef, HomeSeer.PluginSdk.Devices.EProperty.PlugExtraData)

The following confirms that the key was stored as lower case text so PED could not be retrieved using the named key unless converted to lower case

?PED.NamedKeys
Count = 1
    (0): "pedkey"

?PED.ContainsNamed(PEDKEY) 
False

?PED.ContainsNamed("pedkey") 
True