Marc (34) [Avatar] Offline
At almost 600 pages I'm sure Manning is close to saying "enough is enough, already".
Notwithstanding the realities of the technical publishing business, I'd like to suggest either a new section, a "Volume 2", or just a second edition, that includes more details around the sad path.

Listing 5.6 makes the point that exceptions must be caught.
FWIW, I fully agree.
As a server-side programmer I always had a logging mechanism, Operations folks to monitor the log, and HTTP 500 to tell the client side programmers that something just went sideways.

Bringing together Listing 5.6 and SQLite-net-pcl, what are your recommendations for where to 'catch' the exception: repository, service, viewmodel or model?
1. How to expose the failure to the UI?
2. How to inform the developer of the failure details?

Thank you again,
Jim Bennett (88) [Avatar] Offline
Usual answers - it depends!

In chapter 15 we cover App Center to track uncaught exceptions. You can also use App Center events to track caught exceptions (and they have managed exception tracking coming soon), so monitoring is covered.

As for where - it all depends on where you can usefully handle the exception. With a UI based app the best place to handle is at the level of interaction with the user, so in the view model. From there you can report to the user in the best way possible. For example if the exception is due to a lack of internet connectivity you can just show a small indicator on your page, just like in apps like twitter or Facebook. If the exception is invalid data you can highlight it on a form. It all comes down to what the user can do with the exception. If there is nothing they can do, such as an error caused by a server being too busy to handle a connection then your app should automatically retry without notifying the user.