Whats best practise on error messages and error events?

We've got a lot of WS calls, often multiple in one single microflow (using subs, of course). When something doesn't work as it should, we want to provide accurate feedback. The problem is using a variety of messages whilst using error events (which trigger the default error message through the parent microflow). How do you work around this?   Let's say we load a page that GETs data from three different application and want to show the user (or dev) which application is faulty. “An error occured” or “There was something wrong while retrieving the data” isn't accurate. Often using Result!=Empty isn't suffice instead of an error event either, as the result might actually be empty.  What is then best practise to have an error message in your sub microflow be provided to the parent microflow and in the end shown to the user? Possible solution.. The only thing I can think of is creating an empty ‘Error’ object in the main (parent) microflow and use it as parameter across all microflows. During an error event, directly after an error, fill this object with the respective message and push this to the top microflow and show it to the user. That would mean, however, having a parameter across all (sub-)microflows which might not be used at all. Doesn't seem so productive and should actually be a system default functionality.. Error handling modules provides a bit of theory, but not sufficient regarding this matter.
1 answers

We solved it indeed by creating a Log item on the highest level and pass down the line of submicroflows. Gives you the most flexebility. And we delete the object if no error did occure.