Improved Error Handling


Hello everyone! With today’s release you’ll see a new and improved way to handle errors in your Dropsource apps. The To Do list that was on the left of the editor has been replaced by a new Error button and panel you can access at the top right.


We’ve updated the format and content of error messages to make the information clearer and easier to process. You’ll see that each error is listed with an indicator of the relevant components in your app (page, element, request etc) and that we’ve included brief instructions to address each error. You can keep the error panel open at the same time as other modals, so you can continue to see the info displayed as you work to resolve an error.

Our engineers have also extended the error reporting functionality to provide information about build errors (errors you encounter after hitting the Test button, when Dropsource is writing and compiling your app). This should increase the number of cases where you are able to solve your own build fails instead of having to engage with support and potentially wait for a response - essentially empowering you to fix more of your own issues and keep moving forward on your projects.


For more info see the updated error handling section in the help center.

Hopefully this will all give you more control over your ability to make progress on your projects, finding and fixing errors as you go. Having tried it already myself I’ve found it to be much more helpful. Let us know what you think!


Just to follow up with a little more context on the new error panel, it has been designed to make it easier for our engineers to surface usable information about build fails as we encounter them (build fails can be caused by errors that crop up when an app’s source code is being written or compiled). For example, just the day of the release we had a user encounter a build fail which the team were immediately able to generate an error message for, and ultimately add it to the list - so that future users will have this error caught when their project is being validated. This means that as we move forward there will be fewer and fewer cases where users need to wait for support in order to resolve an issue.


Bit more insight into the error panel in this blog post from @catencio


This tool has got to get better. I find myself still having to tear down entire pages because it’s still can’t capture various types of errors. And it’s nothing worse than this happening on the weekend. A whole two days of productivity down the drain. And even doing the week, it still takes too long for support to help with these unknown issues. Just frustrating.


Hi @chris, I understand it can be frustrating not being able to resolve build errors. Our team is constantly increasing the range of errors that return information you can use to resolve issues without requiring assistance - our recent release with the new error panel included a redesign of the build error reporting function that lets the engineers add new errors to the validation list dynamically as users encounter them, so since that release we have added a load more that don’t require support help (and we’ll continue to do that).

Over and above that it’s best to test your project regularly rather than adding lots of new functionality in between builds, that way it’s easier for you to locate the likely source of an error when you do hit an unknown build fail (which are relatively uncommon) - that’s certainly what I do when I’m working in the editor, hit the test button whenever I add any new chunk of functionality.

Ultimately we will always try to reduce the need to rely on support, but what happens when you click that test button is extremely complex, so errors are likely to arise from time to time, as they do when you develop any kind of application. We’re of course trying to narrow down the number of those issues that you’re unable to resolve without needing our team’s assistance.

In terms of support, I’d just mention that we recently hired a fantastic dedicated support person (@wsellers) in spite of us still being a small team, because as a company we really are committed to user success. I would say that for the premium price point we now provide a very high quality support response - as you know, our team members (including engineers) regularly invest significant amounts of time in helping troubleshoot individual user issues.

With all that in mind I’d ask you to try and be patient with us as we continue to improve our tool, and know we will always aim to do our best to help you make progress on your apps and be successful in Dropsource.


Hi @sue,

Happy New Year! I have a question about Build Errors. How do we get support with an error that doesn’t show any details? I don’t have any alerts or anything like that, but I just went through the new shopping cart tutorial and when I attempt to build, I get the following and no further details:

Status: Failed
Test Configuration: Web simulator
Build Date: 01/09/2019 at 3:21 PM
Build ID: 1083141740066701293
This build was unsuccessful.

Are you able to suggest any steps to figuring this out? Thanks.

{Edit : I duplicated my project and started removing things piece by piece. I determined that my 200 response events seem to be the culprit. I’ll check through the tutorial again and try to find the problem. Thanks.}


Hi Jparker,

Catching up here. I see your Edit at the end there and it looks like you may have deduced the issue youself. Let me know if you need more help. In these situations, there’s times where I can download your source code and run it in Android Studio to see what errors are apparent. We do our best to inform on as many errors as possible. This pursuit is an ever evolving 1 as the variety of errors an app can have is quite high. With each error we uncover more truth to, we try to add more info to the error panel for the platform as a whole so that you and the rest of the Dropsource community are better informed without our interjection with each time.