Or catch the top level function and see every exception in your project? Tell me which language does not have a top level main function?

▲

zaphar 4 days ago | parent | next [-]

This is the "I don't care what fails nor do I wish to handle them" option. Which for some use cases may be fine. It does mean that you don't know what kinds of failures are happening nor what the proper response to them is, though. Like it or not errors are part of your domain and properly modeling them as best you can is a part of the job. Catching at the top level still means some percentage of you users are experiencing a really bad day because you didn't know that error could happen. Error modeling reduces that at the expense of developer time.

▲

dingi 4 days ago | parent | next [-]

Top-level error handling doesn't mean losing error details. When done well, it uses specialized exceptions and a catch–wrap–rethrow strategy to preserve stack traces and add context. Centralizing errors provides consistency, ensures all failures pass through a common pipeline for logging or user messaging, and makes policies easier to evolve without scattering handling logic across the codebase. Domain-level error modeling is still valuable where precision matters, but robust top-level handling complements it by catching the unexpected and reducing unhandled failures, striking a balance between developer effort and user experience.

	▲	zaphar 2 days ago \| parent [-]
		If you are actually using specialized exceptions and a catch-wrap-rethrow strategy then you are doing error modeling and you aren't "Just letting them bubble up to the top" which is basically making my point for me.

▲

nromiun 4 days ago | parent | prev [-]

"I don't care what fails" means not catching any exception/error. My comment was the exact opposite of the idea. Top level function will bubble up every exception, no matter how deep or from which module.

▲

_flux 4 days ago | parent [-]

But the case when you actually learn what errors can happen is when your users start complain about them, not because you somehow knew about it beforehand.

Or maybe you have 100% path coverage in your test..

▲

nromiun 4 days ago | parent [-]

So you are talking about bugs that don't get caught in development? That happens in Rust as well. Borrow checker does not catch every bug or error. A random module you are using could throw a panic and you would not know with Rust (or any language for that matter), until your users trigger those bugs.

	▲	_flux 4 days ago \| parent [-]
		It sure does happen. So should we simply give up? Or should we aspire to have tools to reduce those bugs? Knowing what kind of errors can occur is one of those tools.

▲

johannes1234321 4 days ago | parent | prev [-]

Even better: just let it crash an get a core dump with full context information rather than some log missing information.

But often some "expected" errors can be handled in some way better (retry, ask user, use alternate approach, ...)