Is onError handler better than exceptions?
<p>I understand that exception in program means that something unpredictable happened (but not so bad to unavoidably crash the application!). The try-catch-finally sequence makes me sad because the program is harder to read (one more level of curly brackets) and harder to understand (jump from anywhere to catch in case of exception happened, it is deprecated GOTO).</p>

<p>Since we have OOP, I suggest to create proxy class which in case of exception consumes it silently, returns some default value and fires onError event. So if we propagate exception, we have onError call instead, and the two disadvantages mentioned above are solved. See the example in C#:</p>

<p><strong>Standard exception attitude</strong></p>

<pre><code>  class Computer {
    // let's say we need to propagate exception and decide what to do lately
    public int divide(int a, int b) {
      int result = a / b;
      return result;
    }
  }

  class Program {
    public static void Main() {
      Computer c = new Computer();
      try {
        Console.WriteLine(c.divide(1, 0));
      }
      catch(ArithmeticException e) {
        // we are teleported here from the middle of Computer.divide method!
        // do something
      }
    }
  } // three levels of brackets (without namespace) in such trivial example??
</code></pre>

<p><strong>onError handler attitude</strong></p>

<pre><code>  class ProxyComputer {
    private Computer c = new Computer();
    // it is not virtual, can not be overriden
    public int divide(int a, int b) {
      // alas, exceptions are standard, but we can stop them in this class
      try {
        return c.divide(a, b);
      }
      catch(ArithmeticException e) {
        this.onError(e);
      }
    }

    protected virtual void onError(Exception e) {
      // do nothing
    }
  }

  class MoreStrictComputer : ProxyComputer {
    protected override void onError(Exception e) {
      // mail to IT department, revert all transactions etc.
      Console.WriteLine("I can't seem to do that");
    }
  }

  class Program {
    public static void Main() {
      ProxyComputer pc = new ProxyComputer();
      MoreStrictComputer msc = new MoreStrictComputer();
      // fires onError instead of exception
      Console.WriteLine(pc.divide(1, 0)); // no problem
      Console.WriteLine(msc.divide(1, 0)); // this time it won't be so easy
    }
  } // only two levels of brackets
</code></pre>

<p>Often I see empty (or trivial) catch blocks. This means programmers often consider exception as no problem situation, but with standard exception attitude, they still have to bother with try-catch. The second attitude makes it optional.</p>

<p><strong>So the question is:</strong> Which solution would you prefer? Is this some kind of pattern or am I missing something?</p>

<p><strong>Edit</strong> As Paul Equis suggests, <code>throw e;</code> should be default onError behavior, not do-nothing silence swalowing.</p>
