# How should a function report an error?
**URL:** https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266
**Category:** General Usage
**Tags:** question
**Created:** [March 19, 2026, 2:21am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266 "2026-03-19T02:21:00Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 19, 2026, 2:21am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266/1 "2026-03-19T02:21:00Z")
Functions can fail. I have functions that try to find a steady state of a DAE system, and that can fail. What is better:
- to raise an exception
- to return `nothing`
While this error can be fatal, it does not have to be, trying again with different parameters might help.
Extra question:
Should a linter give a warning if a function returns a value or nothing?
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 19, 2026, 2:53am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266/2 "2026-03-19T02:53:18Z")
On this question, I really appreciate the design of Roots.jl. Its high-level API is opinionated and throws on failure, while its lower-level API gives advanced users more control over how to handle non-convergence.
I think that is a very good pattern. A high-level function should usually be safe and explicit by default. But lower-level interfaces can expose alternative failure-handling strategies for users who really need them.
If you do choose to throw, I would also recommend using a custom exception type. That way, downstream code can still recover cleanly with `try`/`catch` when appropriate, without having to inspect error strings or catch unrelated exceptions.
So for me, it depends on the API’s abstraction level.
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [March 19, 2026, 5:20am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266/3 "2026-03-19T05:20:19Z")
For me, `nothing` would be too uninformative.
Similar to `Roots.jl`, I also prefer for internal functions to maybe also just return the error or in some way information what/why things failed – and the high level parts to throw those.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 19, 2026, 6:47am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266/4 "2026-03-19T06:47:41Z")
> [@karei](#):
>
> its lower-level API gives advanced users more control over how to handle non-convergence.
I could not find any lower level API in the documentation of Roots.jl. Which functions are you talking about? How do they report a failure?
---
### Author:  [@karei](https://discourse.julialang.org/u/karei)
#### Post date: [March 19, 2026, 8:17am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266/5 "2026-03-19T08:17:25Z")
> **[CommonSolve interface - Reference/API · Roots](https://juliamath.github.io/Roots.jl/dev/reference/#CommonSolve-interface)**
>
> The Roots package provides several different algorithms to solve f(x)=0. | Documentation for Roots.
> Unlike find\_zero, solve will return NaN on non-convergence.
And `find_zero` will throw `Roots.ConvergenceFailed`.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [March 19, 2026, 10:32am UTC](https://discourse.julialang.org/t/how-should-a-function-report-an-error/136266/6 "2026-03-19T10:32:05Z")
I think I will return the tuple `, error`. I cannot use NaN because my result is not a number. Then the caller can decide to print a warning in case of an error, or to retry with different parameters.