Acknowledged
3 months ago
CIQQA-3258

feature-request: include an example error message in the ERA reports

Currently we only see the error name in ERA. It would be helpful if we could also see at leas one random error's message. At least for exceptions (i.e when we see Unhandled Exception) there usually is an error message that the Monkey C code can see with e.getErrorMessage(). Please include that in ERA Viewer.

In case it's about multiple exceptions, then include at least one such ("random") message.

See also: https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-instead-of-unhandled-exception-give-actual-exception-s-name-in-era-viewer

flocsy🤠
Parents
  • 3 months ago

    > At least for exceptions (i.e when we see Unhandled Exception) there usually is an error message that the Monkey C code can see with e.getErrorMessage(). Please include that in ERA Viewer.

    Like I said in the other bug report, Travis.ConnectIQ already explained that Garmin omits the exception error message on purpose, to prevent devs from smuggling out user data via exceptions. I kind of doubt they're going to reverse course on that. (The problem is that CIQ devs can override getErrorMessage and return any string they want.)

    Travis.ConnectIQ also said an internal ticket had been created to provide the exception class name in the ERA. For the case of standard exceptions, the exception class name should be just as good as the exception error message; in fact it should be better, since you can do an exact search for the exception class name in the API docs, which isn't possible for the exception error message (which is similar, but not identical, to the class name).

Comment
  • 3 months ago

    > At least for exceptions (i.e when we see Unhandled Exception) there usually is an error message that the Monkey C code can see with e.getErrorMessage(). Please include that in ERA Viewer.

    Like I said in the other bug report, Travis.ConnectIQ already explained that Garmin omits the exception error message on purpose, to prevent devs from smuggling out user data via exceptions. I kind of doubt they're going to reverse course on that. (The problem is that CIQ devs can override getErrorMessage and return any string they want.)

    Travis.ConnectIQ also said an internal ticket had been created to provide the exception class name in the ERA. For the case of standard exceptions, the exception class name should be just as good as the exception error message; in fact it should be better, since you can do an exact search for the exception class name in the API docs, which isn't possible for the exception error message (which is similar, but not identical, to the class name).

Children
No Data