--- title: Error Handling and Hiding Errors is Not the Same Thing description: Burying errors by swallowing exceptions, returning null on failure, or logging without preserving the original cause is a common but costly habit. Good error... canonical: https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Error Handling and Hiding Errors is Not the Same Thing | daily.dev og:description: Burying errors by swallowing exceptions, returning null on failure, or logging without preserving the original cause is a common but costly habit. Good error... og:url: https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx og:image: https://api.daily.dev/og/posts/wUQe6luGx.png og:image:alt: Error Handling and Hiding Errors is Not the Same Thing og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Error Handling and Hiding Errors is Not the Same Thing **[Atomic Spin](https://daily.dev/sources/atomicobject)** · 9 min read · 1 upvotes · 0 comments ## Summary Burying errors by swallowing exceptions, returning null on failure, or logging without preserving the original cause is a common but costly habit. Good error handling means preserving the full error chain across every layer of the system, distinguishing between 'no result' and 'something broke', keeping stack traces intact (using bare `throw` not `throw ex` in C#), and making errors actionable with enough context to diagnose the problem. Retries and fallbacks should still be observable. User-facing messages can be sanitized, but internal error detail must survive. Errors are part of the system's interface and should be designed with the same care as APIs. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between throw; and throw ex; in C# when rethrowing an exception? Using throw; preserves the original stack trace, showing where the error actually originated, while throw ex; resets the stack trace to the current location, hiding where the failure really started. When rethrowing a caught exception without modification, throw; should be used; when wrapping it in a new exception type, the original should be passed as the inner exception. _Developers hardening C# error handling can revisit patterns like this through daily.dev when debugging tricky stack traces._ ### Why is returning null from a method like FindUser considered bad error handling? Returning null conflates two very different outcomes: no matching record exists, or a database query actually failed. Treating both cases the same forces callers to guess what happened, which can lead to misleading messages, duplicate records, or workflow bugs. A better design uses a distinct result type, such as a Result, or lets exceptions propagate so failure and absence stay separable. _When designing return types for lookup functions, daily.dev surfaces patterns for handling absence versus failure explicitly._ ### How can retries and fallback logic accidentally hide production problems? If a service call fails and the code silently falls back to cached data, or an operation succeeds only after several retries, nobody may notice that the system is running in a degraded state. Repeated transient failures can signal a scaling issue or an approaching outage, so recoveries should be made observable through structured logs, metrics, or trace spans rather than passing silently. _Teams debugging flaky dependencies can track observability practices for retries and fallbacks on daily.dev._ ## Similar posts on daily.dev - [The two kinds of error](https://daily.dev/posts/the-two-kinds-of-error-zsfcltzzr) · Lobsters · 0 upvotes · 0 comments - [How top software houses handle the work that really matters](https://daily.dev/posts/how-top-software-houses-handle-the-work-that-really-matters-muplyicvz) · TechCentral · 0 upvotes · 0 comments - [What Now? Handling Errors in Large Systems](https://daily.dev/posts/what-now-handling-errors-in-large-systems-qq5qke6ya) · Marc Brooker · 2 upvotes · 0 comments - [The Second Great Error Model Convergence](https://daily.dev/posts/the-second-great-error-model-convergence-e6ligcvol) · matklad · 0 upvotes · 0 comments --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#logging](https://daily.dev/tags/logging), [#c#](https://daily.dev/tags/c#) [View this post on daily.dev](https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Error Handling and Hiding Errors is Not the Same Thing","url":"https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx"},"datePublished":"2026-07-21T12:01:15.616Z","dateModified":"2026-09-13T21:42:50.996Z","description":"Burying errors by swallowing exceptions, returning null on failure, or logging without preserving the original cause is a common but costly habit. Good error...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/760117746d7c184905c166b22d40d14b?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/760117746d7c184905c166b22d40d14b?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Atomic Spin","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Atomic Spin","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/e2af5ce3adaa403a8cf029268b62419f","url":"https://daily.dev/sources/atomicobject"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"general-programming,logging,c#","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Atomic Spin","item":"https://daily.dev/sources/atomicobject"},{"@type":"ListItem","position":3,"name":"Error Handling and Hiding Errors is Not the Same Thing"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/error-handling-and-hiding-errors-is-not-the-same-thing-wuqe6lugx#faq","mainEntity":[{"@type":"Question","name":"What is the difference between throw; and throw ex; in C# when rethrowing an exception?","acceptedAnswer":{"@type":"Answer","text":"Using throw; preserves the original stack trace, showing where the error actually originated, while throw ex; resets the stack trace to the current location, hiding where the failure really started. When rethrowing a caught exception without modification, throw; should be used; when wrapping it in a new exception type, the original should be passed as the inner exception. Developers hardening C# error handling can revisit patterns like this through daily.dev when debugging tricky stack traces."}},{"@type":"Question","name":"Why is returning null from a method like FindUser considered bad error handling?","acceptedAnswer":{"@type":"Answer","text":"Returning null conflates two very different outcomes: no matching record exists, or a database query actually failed. Treating both cases the same forces callers to guess what happened, which can lead to misleading messages, duplicate records, or workflow bugs. A better design uses a distinct result type, such as a Result, or lets exceptions propagate so failure and absence stay separable. When designing return types for lookup functions, daily.dev surfaces patterns for handling absence versus failure explicitly."}},{"@type":"Question","name":"How can retries and fallback logic accidentally hide production problems?","acceptedAnswer":{"@type":"Answer","text":"If a service call fails and the code silently falls back to cached data, or an operation succeeds only after several retries, nobody may notice that the system is running in a degraded state. Repeated transient failures can signal a scaling issue or an approaching outage, so recoveries should be made observable through structured logs, metrics, or trace spans rather than passing silently. Teams debugging flaky dependencies can track observability practices for retries and fallbacks on daily.dev."}}]} ```