# Capturing errors caused inside link-call flows

**URL:** <https://discourse.nodered.org/t/capturing-errors-caused-inside-link-call-flows/80010>\
**Category:** General\
**Created:** [22 July 2023 16:10 UTC](https://discourse.nodered.org/t/capturing-errors-caused-inside-link-call-flows/80010 "2023-07-22T16:10:14Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [23 July 2023 09:15 UTC](https://discourse.nodered.org/t/capturing-errors-caused-inside-link-call-flows/80010/9 "2023-07-23T09:15:40Z")

</div>

Using the `.error` property as indicator is the only way right now. The link return doesn't (and shouldn't) know anything about the nodes connected, that would make it much more complex. I think it should only react on the message.

I think of `.error` as a _convention_ for errors, just like `payload` for data.  
I actually use it that way sometimes to generate an error that is not from a catch node, so I can use the same error handling flow path.

In some of my own nodes (request-response paradigm) I use the presence of `.error` to send an error reply instead of a regular data reply.  
So at least for me, this convention has become a viable best practice.

Of course, using the upcoming group catch feature would reduce the effort of selection the individual nodes significantly. 👍

---

_[View the full topic](https://discourse.nodered.org/t/capturing-errors-caused-inside-link-call-flows/80010)._