midi-components: Improve error reporting

[Holzhaus]

We shouldn't assume that users watch the console all the time, especially
when --controllerDebug is active and the log is spammed with MIDI
messages.

[Swiftb0y]

I'm unable to test this but the code looks fine. Though it definitely has to be tested in practice because ES3 can be very strange some time.

[daschuer]

Who catches the exception? If Mixxx is quit, this can be a party stopper, which is a kind of no go.

[Holzhaus]

If this exception is thrown and the controller mapping does not wrap it in a try-catch-block (which would be weird), then mixxx will open a popup that a script error occurred (as we already do in other cases when the mapping throws an error, e. g. when an undefined value is called as a function).

[daschuer]

OK, so the party is going on in any case, right?

[Swiftb0y]

IIRC yes. Only the current "codepath" is affected. So if the error is thrown in a handler, the handler will not work properly (as expected), if the error is thrown in a constructor or the init method, the error will be shown on startup. The only case where this could break if the error is thrown in the constructor of a component and the mapping is creating Objects while running. In that case the objects wouldn't be constructed and thus the handlers of these objects won't be present. But even in this case, the rest of the mapping would still be functional iirc.

[Holzhaus]

I added this code snippet to my controller mapping:

    this.someButton = new components.HotcueButton({
        group: "[Channel1]",
        midi: [0x9F, 0x02],
    });

Directly after loading the controller, this message popups up:

This is much more discoverable than using print which only prints to the console when --controllerDebug is specified (and my controller output Midi clock signals so I can only see it for the fraction of a seconds before it scrolls off-screen).

[Be-ing]

Can we please defer all the recent controller system related PRs for 2.4?

[Holzhaus]

Can we please defer all the recent controller system related PRs for 2.4?

Why? This PR is tiny and makes sure that broken controller mappings are noticed when coding them or activating the controller, not in the middle of a set.

If you just want to get the 2.3 release out ASAP, I sympathize with that, but there are actual blocking issues that we need to resolve first - most notably #2547. While waiting for responses on that PR, I thought I might fix some usability issues that were bugging me for a while.

[Holzhaus]

Merge? The only change is that this now causes a controller script error popup instead of an easy-to-overlook error message on the console (only shown when you passed --controllerDebug) when you load a mapping that uses Components JS incorrectly. That way we prevent that users now know right away that their controller mapping is broken instead of noticing it during a set when they press the button.

[Holzhaus]

@Be-ing ping

[Holzhaus]

Merge?

[Be-ing]

Doesn't this depend on #2588?

[Holzhaus]

Doesn't this depend on #2588?

Not really, but without #2588 some errors might not open a error dialog, so we should probably merge that PR first.