Anyone who has actually done serious programming can tell you that this is absolutely terrible advice. This post reeks of a fundamental misunderstanding of how exceptions are used in actual real-life application.

I wouldn't go that far. But exceptions are for exceptional events, like a full disk or other events you can't prepare for; not for handling user inputs or edge cases. Throwing an exception should be the last measure, the code should deal with handable problems without 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.

Like you said, exceptions are basically a GoTo statement. And as such they typically ruin any kind of optimization / predictive instruction loading. I definitely avoid using them when I can. For the most part I leave them for developer errors. Things that are meant to be fixed by developers/in development. Like ArgumentOutOfBounds. If it's supposed to end up on the UI then it shouldn't be an exception.

Does your process generate output and terminate as the functional mechanism? Then you don't really need exceptions, you can exit with an error. Exiting with an error, and that error is an uncaught exception, should be considered rude.

Does your process provide a service, or open interactive windows for user interaction as the functional mechanism? Then you should use exceptions, and catch those exceptions.

Good advice, in most languages. I think something people tend not to understand about exceptions is how they tear open the logic of the application that throws them. It's often compared to a 'goto' statement, but since 'goto' is omitted in most modern languages and is pretty much useless, it doesn't get the point across.

tl;dr: Throwing exceptions allows execution to leave a stack frame without popping or pushing.

Code is just lots and lots of functions. Object-oriented languages will fool you, because they have all this nice syntax, but they're actually just making big tables of functions that take 'self' as a hidden argument, where 'self' is a struct that contains all your state (instance variables, etc).

So, when you call a function, the processor has to push all its state (usually just register contents) onto the stack, pass the function arguments (in registers or on the stack) and then advance the base pointer and hand control over to the new function. After the jump, the new function does whatever it's going to do, including maybe repeating this process for yet another function, and then each one "unwinds" the stack when it's done to hand control back to the caller.

Most implementations of exceptions jump out of the stack to wherever the handler is, which means, they have to figure out how not to explode the stack. That's pretty expensive. In good implementations, the compiler will optimize try/catch pairs pretty well, but in many implementations, even pretty basic throws cost a lot.

http://blogs.msdn.com/b/ricom/archive/2003/12/19/44697.aspx http://stackoverflow.com/questions/567579/how-expensive-are-exceptions http://stackoverflow.com/questions/891217/how-expensive-are-exceptions-in-c

One more tip.

If you are confronted with code that does use exceptions a lot realize that that catch statement can be way more simplified.

You can, create a method like this (I need to go to bed, so a draft version to get the idea)

private void ProcessException(Exception e){
    if (e is Exception1) {
         var ex1= e as Exception1;
         log.WriteLine(ex1.Message, ex1.SomeProperty1)
   } if (e is Exception2) {
         var ex2= e as Exception2;
         log.WriteLine(ex2.Message, ex2.SomeProperty2)
   } else  {
      log.WriteLine(e.Message)
}

Now you can use it like this:

public methiod1(){
  try {
   // do something
  } catch (exception e){
    ProcessException(e);
  }
}
public methiod2(){
  try {
   // do something
  } catch (exception e){
    ProcessException(e);
  }
}
public methiod3(){
  try {
   // do something
  } catch (exception e){
    ProcessException(e);
  }
}

It reduces the catch part because it is repetitive and exposes the real functional code from obscurity.

And you can even migrate the ProcessException() to a different class that extends intelligence to report the exception more easily

Except throwing/catching exceptions is a convention in python (ask forgiveness, not permission).
Just take a look at Django, there are a few different types of exceptions that allow you to catch that exception, and handle it accordingly. (eg model DoesNotExist, MultipleObjectsReturned)

my instructor a year ago said as much. She didn't like using exceptions and preferred to use data validation, maybe even reg expressions. I forgot now. Though for some things it's required to throw exceptions.

I mostly agree with the short version. There are times in normal code flow where an exception is a good idea- a lot of it depends on what exceptions are in that specific language. If the goal is to make the code look a bit cleaner, but you are hammering an exception when you should have used a branch, that is usually poor practice.

Phrasing the tip as absolute isn't very good, though. You really need to see what exceptions will do for you and what they will, err, do TO you, and base your decisions on that.