Consider logging exceptions caught by `LoadSupport`

[ghsolomon]

LoadSupport.doLoadAsync catches exceptions thrown by HoistModel.doLoadAsync and updates its lastLoadException observable accordingly. It also includes the exception in the browser console log, at an appropriate log-level. However, it does not log these exceptions on the server.

Consider logging exceptions not marked as routine and not thrown on autoRefresh to the server so they are reported.

Alternatively, app developers should be encouraged to catch and handle exceptions themselves, but our current story is that LoadSupport will only know about uncaught exceptions (or exceptions that are caught, handled, and rethrown).

[amcclain]

Would like to discuss a bit more if this would enable some pattern that's not possible now, or actually reduce boilerplate code.

[ghsolomon]

Discussed this with @lbwexler in the context of a component / model he was working on. He wanted to render an error panel when a model was unable to load its underlying data and leveraged the observable LoadSupport.lastLoadException to do so.

This is different than our (maybe more typical) pattern of wrapping calls in a try / catch and setting some observable error property on the model. Using LoadSupport.lastLoadException is nice in that it cuts down on this boilerplate with one big caveat— exceptions are not logged on the server.

One could work around this by wrapping their throwable call in a try / catch, logging the exception in the catch block, and then rethrowing for LoadSupport to catch. But then I’m not sure we’ve actually saved much code. Would love to discuss more today if you have time.

[lbwexler]

What if we had a template method onLoadException() that you could override? Would be slightly cleaner than the try/catch rethrow. Would allow you to handle the exception in any way you want, but still allow the super class to know about it/store it! Might be generally a nice cleanup for a lot of models to seperate their happy path from their unhappy path.