Flusk new feature, Error Monitoring, will show you all the runtime errors faced by your users enriched with a screenshot of their screen at the moment the error was thrown, with the associated error description.
We offer a free, 14-day trial of you want to give it a try
I’m worried I’m being dumb and missing something obvious here so I’m going to provide a more tangible example.
For my PDF Creator plugin, the user needs to provide the ID attribute of the element they want to PDF. If the user doesn’t provide an ID attribute (or provides an incorrect ID attribute), then no PDF is possible.
I’ve built in some error handling to let the user know they have to provide a correct ID Attribute.
This is the code:
// basic error handling for blank input
if (properties.id_attribute == null) {
alert(
`It looks like the "ID Attribute(s)" input is empty. Please provide us with some element ID's that we can use in the PDF`
);
return;
}
Which results in this error message if the user forgets to add an ID Attribute:
I like this. It helps the user understand what’s going wrong (and saves me quite a bit of time that would have been spent on customer support )
Crucially, the above example is for a client-side workflow.
@rico.trevisan when I feed your Excel/ XLSX Creator plugin (which is lovely) some gibberish (I’m sorry!)…
But is there any way I can actually display this error message to the end plugin user like I did in my PDF example above?
My understanding is I can’t, because it’s a server-side action and I therefore can’t trigger anything in the user’s browser… but it would be really really nice if I could.
Rico already answered well, but I just wanted to add that you can verify that the checkbox “Optional” is unchecked in your plugin editor action “fields”
This will force the app builder who uses your plugin action to fill the ID field with an expression (otherwise Bubble shows an error saying that this field is required), but then you have to implement your own error handling (using try/catch in your plugin action code, throw new Error() inside the “try” and then return errors in the “catch” to make them available as action results). Like this you can check that the result of the expression is in fact not empty, or check other edge cases like an invalid string format for example.