# How do deal with Zig error not being to contain data?

**URL:** <https://ziggit.dev/t/how-do-deal-with-zig-error-not-being-to-contain-data/9683>\
**Category:** Explain\
**Tags:** language\
**Created:** [April 17, 2025, 4:36pm UTC](https://ziggit.dev/t/how-do-deal-with-zig-error-not-being-to-contain-data/9683 "2025-04-17T16:36:20Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![jeffective](https://ziggit.dev/user_avatar/ziggit.dev/jeffective/32/3116_2.png) [@jeffective](https://ziggit.dev/u/jeffective)\
**Post date:** [April 17, 2025, 10:50pm UTC](https://ziggit.dev/t/how-do-deal-with-zig-error-not-being-to-contain-data/9683/7 "2025-04-17T22:50:35Z")

</div>

You might be interested in this thread, and my response, which in short was “error codes are not values, errors are a refusal to return a value”. This is my current understanding of errors. The current default way to return values as “erroneous” is to use a tagged union.

> [@Allow returning a value with an error](https://ziggit.dev/t/allow-returning-a-value-with-an-error/7746/4):
>
> The colloquial meaning of an error is perhaps not well aligned with zig’s error unions. Zig’s error unions could be used to mean “bad thing happened” but it doesn’t fit all use cases. The current design of errors is closer to “a refusal to return a value”. Its like returning null but you have the ability to switch on the errors for control flow. In the issue, Andrew says “error codes are for control flow”. One could also interpret this as “error codes are not informative”, or “error codes are n…

---

_[View the full topic](https://ziggit.dev/t/how-do-deal-with-zig-error-not-being-to-contain-data/9683)._