Java and Rust are the only language that I know of that has proper handling of exceptions; mandatory declaration as part of method declaration, since exceptions ARE an integral part of the contract. (Yes, I consider the Result<T, E> being corresponding to exception declaration, since the return value MUST be checked prior to use of T.)

    func f() throws -> T {
    }

    func f() -> (T|any Error) {
    }

Honestly, I thought the diatribe would focus on needless complexity.

The starting example is how I'd do it in C:

```

void f(const char* p) // unsafe, naive use

{

    FILE \*f = fopen(p, "r");    // acquire

    // use f

    fclose(f);                  // release

}

```

Wouldn't the simpler solution be ensuring your function doesn't exit before release? All that c++ destroyer stuff appears somewhat unnecessary and as the author points out, creates even more problems.

The classic "Frequently Questioned Answers" is the ultimate takedown of this abomination of a language.

https://yosefk.com/c++fqa/

Author completely misunderstands how to use exceptions and is just bashing them. A lot of what he says is inaccurate if not outwardly incorrect.

Also Bjarne's control of C++ is quite limited, and he is semi-retired, so asking him to "fix his language" is fairly misguided. It's designed by a committee of 200+ people.

Anyway what you want seems to be to not use exceptions, but monads instead. These are also part of the standard, it's called std::expected.

  class File_handle {
      FILE *p;
  public:
      File_handle(const char *pp, const char *r)  { p = fopen(pp, r); }
      ~File_handle() { if ( p ) fclose(p); }
      FILE* file() const { return p; }
  };
  
  
  void f(string s)
  {
      File_handle fh { s, "r"};
      if ( fh.file() == NULL ) {
          fprintf(stderr, "failed to open file '%s', error=%d\n", p, errno);
          return;
      }
      // use fh
  }

This is a common problem with try-catch syntax. An alternative, and arguably more useful syntax would be

  try (File_handle fh {s, "r"}) {
    // use fh
  } unless (const File_error& e) {
    // handle error
  }

Where the "use fh" part is not covered by the exception handler. This is covered (in ML context) in https://www.microsoft.com/en-us/research/publication/excepti...

>The first is that our error message may not be correct. It’s possible that the exception we’ve caught was not introduced by opening this file, and, the errno may not reflect the errno at the time fopen was called.

All that is needed is a better File_error type that includes the error that happened.

  void f(string s)
  {
      try {
          File_handle fh { s, "r"};
          // use fh
      } catch (const File_error& e) {
          fprintf(stderr, "File error: %s\n", e.msg.c_str();
          return;
      }
  }

The first two problems can be solved in a straightforward way with more custom exception types. For the "bigger problem", catch(...) can be used to prevent your code from crashing. If you really want to handle each case explicitly you could also use enums in combination with compiler flags that enable exhaustive checking.

This post completely misunderstands how to use exceptions and provides "solutions" that are error-prone to a problem that doesn't exist.

And this is coming from someone that dislikes exceptions.

It's a bad post, but I find it funny someone thinks C++ can be fixed (:

I didn’t really understand the writer’s comments with exceptions and I don’t code in C++.

Their main complaint about exceptions seems to be that you can’t handle all of them and that you don’t know which you’ll get? If we compare this to python, what’s the difference here? It looks like it works the same here as in python; you catch and handle some exceptions, and others that you miss will crash your program (unless you catch the base class). Is there something special about C++ that makes it work differently, or would the author have similar problems with python?

I agree with the other comments that this understanding of exceptions is wrong. He's not wrong about these two points:

- Correctness: you don’t know if the exception type you’ve caught matches what the code throws

- Exhaustiveness: you don’t know if you’ve caught all exceptions the code can throw

But that's actually not a problem. Most of the time you shouldn't catch a specific exception (so always correct) and if you are catching then you should catch them all (exhaustive). A better solution is merely:

    void f(string s)
    {
        try {
            File_handle fh { s, "r"};
            // use fh
        } catch (const std::exception& e) {
            printf(stderr, e.what());
        }
    }

That's all you need. But actually this code is also bad because this function f() shouldn't have a try/catch in it that prints an error message. That's a job for a function (possibly main()) further up the call stack.

My biggest beef with exceptions is invisible code flow. Add the attribute throws<t> to function signature (so that its visible) and enforce handling by generating compiler error if ignored. Bubbling up errors is OK. In essence, this is result<t,e>. Thats OK. Even for constructors.

What I dislike is having a mechanism to skip 10 layers of bubbling deep inside call stack by a “mega” throw of type <n> which none of the layers know about. Other than

If you use names that frigging bad, exceptions are the least of your problems.

All this hassle can be avoided by using `cleanup` compiler attribute.

Manage classical C resources by auto-cleanup variables and do error-handling the normal way. If everything is OK, pass the ownership of these resources from auto-cleanup variables to C++ ctor.

Note this approach plays nicely with C++ exception, and will enter C standard in the form of `defer`.

Or do without exceptions for control flow. For example Elixir does have try/catch but it's used very rarely because most functions return tuples with the first element being either :ok or :error. Then we can pattern match it and return an :error to the caller if we have to, possibly bubbling up several levels return after return. Or let the process crash and restart while the rest of the application keeps running. A surprising number of errors eventually fix themselves (API calls, disk space, missing data) when you design the system to attempt more times to complete its tasks. That's not only a characteristic of Elixir and the BEAM languages. You can do it more or less easily on any language. Maybe you need a queue and workers reading from the queue and all it takes to manage them, and BEAM makes it convenient by including most of it.

The page about try/catch explains it well https://hexdocs.pm/elixir/try-catch-and-rescue.html