<commit_before># Types of exceptions

There are three types of exceptions:

* the ones that we are expecting
* the ones that we have to catch
* the fatal ones that will cause the app to crash

For the first type:

We should handle them in our code, don't have to re-throw, don't have to send it to fabric.
For example, something exception happens in UI, we catch it, show a toast, then we can forget about it.
After all, it's an expected exception and we know what to do when it happens.

For the second type:

We should wrap them up in a LMISException and call reportToFabric to report it to server.

For example, an API from some 3rd party lib is has throws XXXException on its signature, it does not happen under normal circumstances, 
but since it has the exception on its signature, we have to catch it.

But when it does throw that exception, that means something out of our expectation has happened, we wanna know, that's why we send it to fabric.

For the third type:

For example, an API call may cause a RuntimeException, we can either re-throw it or just let it pop up to higher level of stack and blow up the app.
When the app does blow up, fabric will automatically report a fatal issue.
We should not eat this type of exceptions up, since it leaves the app in a nondeterministic state.

# Fatal and non-fatal issues

When the app blows up because of a unhandled exception, fabric automatically uploads it as a fatal issue.

Non-fatal issues are the ones created by us calling LMISException.reportToFabric.

# Availability of error reports

Since the devices in health facilities do not always have network connection, the error reports that we send to fabric follows
a strategy that's similar to how we sync stock/requisition data.
 
For fatal issues:

Fabric tries to send fatal report to server right after it happens, but if network is not available at the time, the error report will be saved
locally, and Fabric lib will retry to send it next time the app is started, until it gets any luck with the network.
 
For non-fatal issues:

Non-fatal issues are always saved locally and later on sent to server when network is available.<commit_msg>CPF - #380 - more details in the doc<commit_after># Types of exceptions

There are three types of exceptions:

* the ones that we are **expecting and know how to handle**
* the ones that we **don't know how to handle, but are catching anyways**
* the fatal ones that will cause the app to **crash**

For the first type: 

We should handle them in our code, don't have to re-throw, don't have to send it to fabric.
For example, something exception happens in UI, we catch it, show a toast, then we can forget about it.
After all, it's an expected exception and we know what to do when it happens.

For the second type:

For example, an API from some 3rd party lib is has throws XXXException on its signature, it does not happen under normal circumstances, 
but since it has the exception on its signature, we have to catch it.

But when it does throw that exception, that means something out of our expectation has happened, we wanna know.
We should wrap them up in a LMISException and call reportToFabric to report it to fabric server.

For the third type:

For example, an API call may cause a RuntimeException, we can either re-throw it or just let it pop up to higher level of stack, both will blow up the app.
When the app does blow up, fabric will automatically report a fatal issue.
We should not eat this type of exceptions up, since it leaves the app in a nondeterministic state.

# Fatal and non-fatal issues

When the app blows up because of a unhandled exception, fabric automatically uploads it as a fatal issue.

Non-fatal issues are the ones created by us calling LMISException.reportToFabric.

# Logs during development

LMISException.reportToFabric will also print the exception to console, so we are not losing the e.printStackTrace info during development.

# Availability of network

Since the devices in health facilities do not always have network connection, the error reports that we send to fabric follows
a strategy that's similar to how we sync stock/requisition data.
 
For fatal issues:

Fabric tries to send fatal report to server right after it happens, but if network is not available at the time, the error report will be saved
locally, and Fabric lib will retry to send it next time the app is started, until it gets any luck with the network.
 
For non-fatal issues:

Non-fatal issues are always saved locally and later on sent to server when network is available.
{'fraction_non_alphanumeric': 0.033559991226146085, 'fraction_numerical': 0.0010967317394165387, 'mean_word_length': 4.117845117845118, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1971118', 'n_tokens_mistral': 1162, 'n_tokens_neox': 1115, 'n_words': 785}