Acknowledged
7 days ago
CIQQA-3253

bug / feature-request: instead of "Unhandled Exception" give actual exception's name in ERA Viewer

We're getting lots of "Unhandled Exceptions" in ERA, but there's no such exception. I don't see any reason why Garmin would intentionally hide the real exception form the developers (especially that the documentation mentions some possible exceptions)

My problem is with Properties.setValue. I am pretty sure it's not any of these, or at least it shouldn't be:

flocsy🤠
  • 7 days ago

    We're getting lots of "Unhandled Exceptions" in ERA, but there's no such exception

    I hate to state the obvious, but "Unhandled Exception" means that an exception was thrown which the application did not catch (i.e. the application did not "handle" the exception). It is simply a description of the error condition that caused your application to terminate (similar to "Out of Memory" or "Invalid Value").

    It is clearly not meant to imply that there is an exception that's literally named "Unhandled Exception" or "UnhandledException", as you are suggesting with "there's no such exception".

    In other words, an "unhandled exception" isn't a *kind* of exception (akin to StorageFullException, for example), it's just an exception that wasn't handled.

    That doesn't really take away from your feature request, but I thought it was a strange choice of words.

  • 7 days ago

    TL;DR

    - even regular (non-ERA) crash logs omit the literal class name of the exception, but actually contain the result of Exception.getErrorMessage

    - this error message is omitted from ERA logs for privacy reasons

    - there is an internal ticket to effectively add the exception class id/name to ERA logs and regular crash logs

  • 7 days ago

    We're getting lots of "Unhandled Exceptions" in ERA, but there's no such exception. I don't see any reason why Garmin would intentionally hide the real exception form the developers (especially that the documentation mentions some possible exceptions)

    Note that the exception message see you see in a normal crash log [e.g. when debugging locally or via debug sideload] is not literally the class name of the exception, but it's the error message returned by Exception.getErrorMessage (which is usually close enough to the class name that you can guess which exception class it refers to).

    It's been mentioned in the past that the exception message is omitted from ERA logs to prevent apps from covertly smuggling out user data via exceptions.

    Source:

    https://forums.garmin.com/developer/connect-iq/f/discussion/193579/era-crash-log-viewer---check-it-out-if-you-haven-t/942192#942192

    Travis.ConnectIQ said:
    can a developer change the debug.xml content , provoke a crash and get this data via ERA ?

    No.

    We don't send exception strings or error messages that the developer may manipulate to smuggle data off of the device. We sell these devices in Europe, so we are bound by GPRD to not send anything that could be used to personally identify anyone.

    We currently capture the following data when a crash occurs:

    • time/date of the crash
    • device part number (this tells us what device model was used, this is not the unique device id)
    • device firmware version
    • active language
    • ConnectIQ SDK version used to build the app
    • ConnectIQ app store id (to identify the crashing app)
    • ConnectIQ app store app version
    • name of the .PRG file that crashed
    • name of the app that crashed
    • stack trace of the crash
    • the crash type (out-of-memory, symbol not found, ...)

    The entire crash log is uploaded, but some of this data is not used by the ERA system. For example, the PRG and app name are there to help users locate and eliminate problem apps on the device and is not useful in reporting crashes via the ERA service.

    With regards to the actual exception class name, Travis.ConnectIQ said this 7 months ago:

    https://forums.garmin.com/developer/connect-iq/f/discussion/388311/array-data-size-limit/1849875#1849875

    We can get the exception class name in a debug build pretty easily. In a release build that requires access to debug.xml and post-processing as is done with the ERA service.

    I'll file a ticket to add the exception class id to the log and some lookup mechanism on the backend for the ERA service.

    So it seems there is already an internal ticket to address what you are asking for.

  • 8 days ago

    I get the error in line 15.

    My properties have ls:

    <property id="ls" type="number">0</property>
    So I'm pretty sure it's not called from background app, the key is a string and it exists in the properties.
     
    Also if mainView is not null, then both hikerView and activityStepsAtPrevious lap are always set (they are non nullable and I compile with typecheck : strict)

    I see that many had similar questions/reports in the past:

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/still-error-name-unhandled-exception-when-calling-toybox-application-properties-getvalue

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/va-voactivea-3-7-70-getproperty-unhandled-exception

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/how-to-debug-an-unhandled-exception

  • 8 days ago

    Because this is my code looks like:

    I get the error in line 15.