To this day, I'm constantly surprised how developers who are more experienced and senior than me, DO NOT use try-catch wraps around their code before pushing it onto the production server.

Developers like these have such a high level of confidence that scares the crap outta me.

Depends on a codebase, if its decent then yeah u can risk

What kind of errors are expected in that block of code?

Let me tell you, when your goal is 80%> CodeCoverage by tests and all your branches are constantly tested by SonarQube for this explicit reason, all those Try Catches are just getting in the way man. Much more efficient to just do one big error handling at the end of the flow, or you know... non at all and just decide that its the callers responsibility to give you the correct input rather than you giving useful help output

some exceptions are *exceptionally* hard to test using Unit testing :)

I don't use try-catch often myself. I have catch-guards at higher levels of the code which will catch exceptions anyways

Honestly it depends on framework and codebase. I know SailsJS provides two methods intercept() and tolerate() so you can chain error handling onto an async/await call rather than wrap everything in a try catch block.

Just because a developer isn't using try/catch explicitly doesn't mean that they are not handling errors at all.

Why catch exceptions all over the place as standard? Exceptions bubble, and an exception is exceptional and shouldn't be something you planned for (sometimes you have to).

Wrapping everything in a try catch doesn't mean errors get handled gracefully, if anything it just means you have plenty of places that can swallow the error. Better to fail fast and fix it.

Have 1 place catching exceptions that by definition can't be planned for, use that to make it not look shit to a customer.

@Crost this!

Fail fast is better than side effects. Unless you wrap file ops or other transactions, try...catch serves as an interceptor for unexpected cases. If one expects them throughout many modules by covering little holes, there is seriously something wrong about such approach.

Fail fast in as many layers as you can and have a try/catch at the entry point to the app (like an mvc controller or message handler or something).
They probably don’t have them because there’s nothing you can do about the exception, so one exception handler to log it and return some kind of error code will likely be enough.