Garmin addresses what I said as follows:

[https://developer.garmin.com/connect-iq/monkey-c/exceptions-and-errors/]

Exceptions and Errors

Monkey C supports structured exception handling for non-fatal errors from which there can be recovery. The syntax should be familiar for Java and Javascript developers:

...

You can use the throw keyword to throw an exception.

...

Errors

Because Monkey C uses dynamic typing, there are many errors for which the compiler cannot check. If the error is of high enough severity, it will raise an fatal API error and cause your app to terminate at runtime. These errors cannot be caught.

Note the clear use of two distinct categories: exceptions (which represent non-fatal errors) and fatal "API" errors. (Yes, some of the doc was clearly written before compile-time type checking was added to the language)

Ofc the fact that "Unhandled Exception" is a fatal error kind of muddies the waters (if an exception is caught and it's not thrown, that's literally a fatal error), but hopefully it should be clear that any error message which does not have the word "Exception" is not referring to an exception at all.

Iow it's a fatal error to not catch an exception that was thrown, but that doesn't mean that other fatal errors are "uncatchable exceptions" - those other fatal errors have nothing to do with exceptions.

It probably also doesn't help that there's an InvalidValueException (which obviously can be caught), but there's also a "Invalid Value" fatal error, which cannot be caught.

Again, it's notable that CIQ apps can define and throw their own Exceptions, but a CIQ app cannot define a custom fatal error which can be used to terminate the app on demand (at least not without using some private API that we devs can't access). 

(Ofc nothing prevents a CIQ app from triggering a known fatal error, like Array Out of Bounds.)

TL;DR

exceptions:

- exceptions represent non-fatal errors

- exceptions are implemented by the Exception class

- exceptions are thrown and can be caught by the application code

- exceptions generate a fatal error / crash if thrown but not caught

- custom exceptions can be defined by app by inheriting from Exception

- app can throw any kind of exception it wants at any time

- "uncatchable exceptions" are not a thing

fatal errors:

- a fatal error always results in an immediate crash; a fatal error cannot be "caught"

- fatal errors are defined and generated by API code only (or to be more specific, non-3rd party code. I assume that Array Out of Bounds is an error that happens at the VM level, not the API level, for example)

- 3rd party app code can't define new fatal errors

- 3rd party app code can't generate fatal errors on demand (except indirectly, by running code which is known to generate fatal error)

- failing to catch an exception is a fatal error, but fatal errors are not exceptions

I realize most or all of this is known (more or less), but I think it's important to use the correct terminology to ensure everyone is thinking about the concepts the right way, otherwise it leads to possible misunderstandings as seen above.

Speaking of terminology:

"I would expect ERA to display all exceptions that result in an app crash—this includes both uncatchable exceptions and any catchable exceptions that are not handled by the code."

Actually the ERA only ever displays fatal errors (including the Unhandled Exception fatal error), and never displays exception details.

Notably, the ERA does not include the exception error message (returned Exception.getMessage) - to prevent smuggling out private user data via the exception message - although this message is shown when debugging locally in the sim.

The ERA also does not include the exception class name, which has been a sore spot for a while (there's no way to know *which* exception was unhandled). It's been mentioned by a CIQ team member that an internal ticket was created to get the exception class id/name added to the ERA, but this hasn't happened yet afaik.

(Note that the exception class name is not displayed when debugging locally, either. It just so happens that the exception message usually resembles the class name, so it's easy to figure out which exception was thrown when you have the message)

FlowState said:

when the log says "Unhandled Exception",

Exactly, that's why I opened this: https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-instead-of-unhandled-exception-give-actual-exception-s-name-in-era-viewer

It is already hard enough to fix these problems, why making the developer's work even harder by hiding from them the real exception's name?

And I opened another: https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-include-an-example-error-message-in-the-era-reports