Catching errors in Espruino Modules (SX127x)

Sun 2020.09.27

Good Afternoon @user114366!

Thank you for clarifying the literal 'uncaught' exception error, the full snippet and the exact error as shown.

Still not at a development PC to test, so going from memory here and wanted to respond timely as I know your time is limited to the weekends.

'I don't quite understand what you are suggesting. Which properties could I test against undefined?'

I had hoped that the review of the var's value and use of dump() from last week would have triggered the answer.

Opening module SX127x.js I searched for the error that is displayed.

L134     SX.prototype.init

L304    this.init.bind(this)

L619    exports.connect

'why throw an error if you are prevented from handling it'

Agreed, and as the statement

'I'm not so concerned with why it fails right now'

led me to believe it is comm that is causing the error to be thrown, and the #1 snippet is what I actually do when loading an unknown module. It is quite possible that as we have a module SX.init() called from within E.on() own init function, and there may be some reason the bubble up error is not able to be trapped.

I perform my test circa 1V95 in it's own function outside of init().

'Which properties could I test against undefined?'

My conception was to test the value of sx L27 as from L619 the returned 'SX' object will overwrite the sx value of 'undefined' in your code.

Another trick I use is to test the var value of assigned constants in the called module. In this case:

L5    var REG = {

Should the module not be fetched, var 'REG' won't exist in the namespace and may be checked using dump(); and will contain the module constant data, and not 'undefined' when Espruino successfully loads/parses the module.

'why throw an error if you are prevented from handling it?'

I'm with you here, but in defense of the author, from line 3 within:

http://www.espruino.com/SX127x

In bold text: 'however it is extremely beta'