Phoenix metropolitan area.

Looks like you exceeded your provider's CPU limits. I'm getting forwarded to https://www.hostinger.co.id/cpu_exceeded?billyhalim.xyz

Only if you designed the code yourself and know every part of that code. But you will fail when you get back to that code 2 years later and have to fix issues.

Not true at all. I've come along on a number of brownfield projects and could always immediately understand even the bad exception handling.

I've never avoided exceptions. The projects I've worked on have never avoided exceptions. And very little of my time in even an entire work year is spent on perplexing exception handling. I think you've had some bad experiences and are severely blowing things out of proportion. Maybe you came into a project that had severely poorly designed exception handling? Is it the language you're using? Does your language have bad tool support that prevents you from quickly understanding call hierarchies?

The 2 epic sentences I always hear are : I don't understand my own code anymore that I created last year. No, we won't change that because it works and we don't want to break stuff. It is too hard to fix.

Taking these and putting them on exception handling is really distorting the issues. In the first case, that's true of many developers and the code they write regardless of whether they use exceptions or return codes. The second case is another red herring. In a work environment, when anything is said to be "too hard to fix", what that means is it's too costly to fix. In other words, if it costs $15k in developer time, it better produce $15k in profits as either a feature or reducing further maintenance. And again, this does not result from using exceptions or return error codes. I've seen plenty of code that is a nightmare to work on because it's had new implicit requirements thrust upon it for over a decade and has been retrofitted with duct tape and hope to get by. It can be littered with bad programming practices (floating point equality comparison, unsynchronized multi-threaded variable access, etc.), and yet the thing still works. So you don't dare go in and change it just to make it "right" as that may break the way it's working now. "Fixing" one of these things may require you addressing a mountain of a problem. It's a case where you grab that first string, and now you have to unravel the whole sweater. And none of this is made more or less complex by return values or thrown exceptions. Both can be done equally well or equally poor as far as understanding and maintenance is concerned. I implore you to investigate outside of your current context. The whole world is not doom and gloom when it comes to exceptions.

This is fairly poor and naive advice as should be guessed from the absolutionist tone.

Throwing an exception for recoverable error like a printer not online, will jump to the location where the the first catch will catch it. But that is runtime depended. And a moving target to debug. It ads code complexity because you have to catch that exception everywhere

I'm not sure what you mean here. Where the first catch catches an exception is entirely detectable through static analysis. I can mentally walk through any code I've touched in the past 5+ years and tell you exactly where a thrown exception will be caught. I do this kind of analysis on a near daily basis with a fair bit of ease. I'm not sure what kind of tooling or language you're using where this is the case.

Throwing an exception can cause instability problems in your code. You tend to end up with partial initialized objects and therefor in an unstable condition. Recovering code becomes messy fast.

This only happens if you don't know how to catch and handle exceptions properly. If at the end of exception handling, your code isn't prepared to continue execution in a correct state, then you're doing it wrong. In my experience, recovery code is rarely complex unless you're trying to do too much at once. Generally, the whole affair at that point should be considered a code smell worthy of deeper investigation.

Not all errors are critical. Sometimes it is enough to recreate a missing file and retry. The code that detected the error most likely can also repair it. It is not the job of some complete different part of the code to repair.

Yes. Strawman argument here. If exceptions are your only tool, then every problem looks like a nail. But they aren't. Don't use exceptions for normal control flow. This is a d'uh, and not a reason to not use exceptions ever.

Triggering 100's of exceptions means that you can't use the debugger to find a critical bug in your software. It is annoying as hell when it jumps to debug mode every single time.

Not sure what kind of programming environment you live in, but thanks to the fact that I can fully inspect a caught exception, I can know exactly where the error is without even debugging (hint: logging + stack traces). I'm also not sure what you mean by triggering 100s of exceptions. Generally, one exception is thrown at one location and caught and handled at another (perhaps rarely rethrown for the sake of adding information pertinent to a higher level of abstraction). But it's not like your whole application is going to throw all of its exceptions at once or constantly be in a state of throwing exceptions. This point alone wreaks of exception inexperience.

Avoiding throwing exception and rely on function results is very helpful to test you code during development simulating errors you introduce by overriding the return variable.

Let me try this: "Throwing exceptons is very helpful to test your code during development simulating errors you introduce by manually throwing an exception." See? This door swings both ways and doesn't at all negate using exceptions.