Hey I would love to know if you guys have this in your plans, @emmanuel I see messages from back in Sep that the proper error handling is in the list but “not imminent”; if there’s a workaround or a hacky solution, I’d love to at least a quick guide which we can use to refer to. a little bit of transparency will help us understand the situation better and appreciate the platform.
Bumping this to see if there have been any changes regarding this issue.
Re-iterating on this subject. Error handling is key to any proper development and is really missing in Bubble. This is becoming more and more urgent for my needs.
I don’t quite get why this has been hard for Bubble to implement. Everything else in Bubble seems very very Node-like.
Most (many?) APIs will do exactly what’s expected in node: return data if success, return error object if error.
If you’re writing your own APIs for use with Bubble, the workaround is to make your success objects include an error key that you populate with something like the error message on error.
(All that works great, but of course Bubble should have a built in error object tied to API data and action calls that one can simply test.)
Anyway, for cases where it’s essential for an error to “bubble” up to the user level, you basically have to shim your calls to external APIs in order to convert error objects into something Bubble can deal with. It’s more work than it should be, but seems like enhancements to API Connector are lower priority than a bunch of other things…
I am looking for this as well. It’s really clunky to have JSON errors popping up for users and there seems to be no way (without hacking it together) to display meaningful error messages to the user.
Can go part of the way there with the server-side scripts, a small prototype on this page: https://toolbox-example.bubbleapps.io/version-test/serverscript
While this hasn’t been updated, my solution has been to use external endpoints (can be AWS lambda or whatever you’re comfortable with, I’m using Python/Flask). These endpoints make the error prone calls, do error handling, and pass data back to bubble.
Though setting the endpoints up might be slightly annoying at first. I like the flexibility it provides with handling requests and dealing with things like nested fields. It also has the added benefit of letting you use SDKs and external libraries, which tends to make processes less stressful.
Bumping this thread - and @gevestobs same… I’ve been constructing Express/Node servers to handle endpoints. Agreed with your point - it does allow for flexibility, although 1) its tricky to use these combined with bubble workflows (ie., if there’s an error, don’t create this item!)… and 2) it’s beyond the ability of your average bubble no code user and against the ‘no code’ ethos of Bubble. Overall, frustrating.
I am also looking for a solution to this …
In this case, you could use a workflow of type ‘An unhandled error occurs’. This WF will catch the error caused by a user signing in with an email address that already exists.
Although Bubble should merge accounts automatically (if we want to). This has been requested here: Email account linked with social media
this feature is only available in page’s workflows, not in API Workflows
That’s right. He can use it at a page level to manage authentication issues.
hey @Bubble team please prioritize this. This makes API connectors useless. It is ok for API-s to return errors in some cases and they need to be handled properly.
Bug, Bug, Bug alert. Seems it is a bug. When API connector call is called when page is being loaded “An unhandled error occurs” event is not triggered. But when I call the same API connector call after a button click then “An unhandled error occurs” event is triggered. @Bubble can you have a look on this?
I suggest you to send a bug report with a specific example (with a video if possible) so
that Bubble can validate on their side.
Did anyone find a fix yet? I need to hide external API Errors from the user.
I built a calculator similar to the BMI Calculator video @bubble posted, by using the math.js API. I set up multiple inputs that calculates a result on the fly. But I also added a submit button to deliver the inputs to my database. The problem is, the math.js API reads an error when the inputs are blank. I don’t allow “submit” to be pressed without the inputs filled. However, the external API still sends the error based on the originally empty inputs. I don’t want the user to see this error. The workflow still works and all the data is delivered and calculated correctly - but the error is sent to the user based on the initial data (which I need blank to start).
If bubble would be willing to continue with the BMI calculator video, I would suggest:
- Add a submit button to the BMI calcualtor
- Recreate the external Api error from math.js when inputs are empty
- Then show us how to hide the error message from users.
Maybe @romanmg would be interested in the next short video topic (her videos are amazing btw)?
I ran into this problem too because I need to access an URL that is sent in the header of an error response. No news here I suppose?
Oh wow! I’ve just ran into this error whilst testing a postcode looking on my site and despite the fact that I have created conditions to handle all of the errors it wont work because bubble shows their own error message which shows the user what API service that I’m using and doesn’t even display a professional message.
This is actually ridiculous! Surely there must be a solution… I cannot launch the app like this! People mistype postcodes all the time
Cracked it thanks to @romanmg at coachingnocodeapps… I’m a member of her VIP group and she had a tutorial on bubbles ability to handle workflow errors.
I actually tried this and it didn’t work but in one of her tutorials she pointed out the “An element has an error running a workflow” option and when I linked this up to the button is worked!
My postcode feature now works perfectly without the ugly default notifications popping up… I have no idea why the catch all version didn’t work but I’m very happy that it’s now working as it should be!!!
Good for you.
I thought it was about Backend Workflows (formerly “API Workflows”)