Under Review
over 1 year ago

Still Error Name: Unhandled Exception when calling Toybox.Application.Properties.getValue

win/eclipse/4.1.7


Error Name: Unhandled Exception
Occurrences: 9
First Occurrence: 2023-03-09
Last Occurrence: 2023-03-10
Devices:
    epixTm (Gen 2) / quatix® 7 Sapphire: 8.23            <= no current firmware
    Instinct® Crossover: 11.18                                    <= the newest one

I've just realised that problem can be connected with no memory. Why?

- in app.onStart() I read STRING properties and no error

- in app.getInitialView (so after onStart()) I read BOOLEAN properties and error

So problem can be with properties of type="boolean" but not everyone have this error (e.g. I have never had it on my f6p in all my apps).

Maybe problem is with bad saving BOOL with GCM on ios (I use android) or GE (i don't use it at all).

_psx_
Parents
  • over 1 year ago

    I haven't yet had time to try to reproduce, but this sounds similar to issues we had a long time ago related to values being save/restored in a way that caused some type confusion. You'd get a value that is supposed to be a Boolean/Number/Float/Long/Double, and it would actually be a String. This led some of us to write code like this to try to coerce the bad type...

    https://forums.garmin.com/developer/connect-iq/f/discussion/2407/issue-debugging-settings/16718

    It isn't ideal, and you should not need to do this, but it can avoid app crashes. In the worst case it would act like your app isn't saving settings.

    Note that Properties.getValue() is the newer way to do this, but the result should be the same as Application.getApp().getProperty().

Comment
  • over 1 year ago

    I haven't yet had time to try to reproduce, but this sounds similar to issues we had a long time ago related to values being save/restored in a way that caused some type confusion. You'd get a value that is supposed to be a Boolean/Number/Float/Long/Double, and it would actually be a String. This led some of us to write code like this to try to coerce the bad type...

    https://forums.garmin.com/developer/connect-iq/f/discussion/2407/issue-debugging-settings/16718

    It isn't ideal, and you should not need to do this, but it can avoid app crashes. In the worst case it would act like your app isn't saving settings.

    Note that Properties.getValue() is the newer way to do this, but the result should be the same as Application.getApp().getProperty().

Children
  • over 1 year ago in reply to jim_m_58

    Try/catch for not existing key can happen usually only in developing time, by typo, I know the name of all properties!

    Ok, it can can be useful to something. I don't expect, that system read only part of properties due to no memory.

    Here we don't speak about Properties.InvalidKeyException.

  • over 1 year ago in reply to Travis.ConnectIQ

    Ciq doesn't give me a chance to check anything because it's in system part.

    ..//here ok, so reading properties...

    var v =Toybox.Application.Properties.getValue(keyString); //ERROR

    ...// unfortunately can't check v because line above was Error Name: Unhandled Exception

    Reproducing is difficult as I've mentioned, not everybody, not every device have this  errors.

    Similar behaviour I can emulate even on sim

    - run app with has properties e.g. 1kB

    - fill memory to any member (e.g. table in app) above (limit - 1kB)

    - run properties editor and save - settings in memory monitor disappear in console 'can't serialise...'

    - try to read properties e.g. onSettingsChange

    I've described this scenario many times. It's reproducible, so this bug should be fixed many months ago. How can dev write good app with such big.

    one more thing, why there is no 'no memory exception' to catch  or returning null when trying create new object and no memory. If you have app where memory consumption depend on external source (user data), again,  it is impossible to write good app. Memory exception' handling should be the first thing made in any api.

  • over 1 year ago in reply to Travis.ConnectIQ

    Yes, it's even mentioned in the New Developer FAQ:
    https://forums.garmin.com/developer/connect-iq/w/wiki/4/new-developer-faq#settings-crash

    With Properties.getValue(), that can throw an exception if the key doesn't exist for some reason, so I use try/catch for that, and I still include the wrapper in all my apps that use settings.