Using exceptions would be unprofessional. If someone were to use exceptions, then all of my carefully crafted error-handling routines would go up in flames because someone's library decided not to use an algebraic data type for conveying error messages across boundaries. It's bad enough that C libraries can suffer catastrophic failures bringing the entire stack down. I want a consistent error-handling strategy, and pattern matching is the best method of clearly displaying intents and possible downfalls.

> Using exceptions would be unprofessional. Unless it happens to be the best tools for the particular scenario...

> then all of my carefully crafted error-handling routines would go up in flames

No just sandbox the code inside a try catch...

> pattern matching is the best method of clearly displaying intents and possible downfalls.

You are stating an opinions as a fact here.

> No just sandbox the code inside a try catch...

This works fine if it's just a matter of rolling back a database transaction or releasing file handles (b/c someone else is doing all the work for you). But if you have more complicated invariants, your try catch has to handle restoring those invariants, no matter what path your code took.

I'd recommend taking a look at Common Lisps condition system, which does exceptions right.

The most important feature is that catch blocks are executed before the stack is unwond, providing the ability for a handler to signal back to the context where the error occurred how it should be handled.

It's sad that no other languages implement this and instead simply decide that exceptions are bad.

Fun trivia: Rust had conditions! Nobody used them, so they were removed.

That sounds short-sighted to me. Even in Lisp restarts (i.e. the feature that allows a handler to communicate back to the point where the exception was thrown) aren't used that often, but when they are, they are incredibly valuable.

In TXR Lisp, a continuable exception occurs every time you see a warning about something in the code, like an unbound variable. It is intercepted higher up and automatically continued.

The code expander has an entry point which allows the caller to be informed about what variables and functions are free in a block of code. The implementation of this entry point works by intercepting warning exceptions about unbound symbols, and accumulating them in in lists, which are then returned to the caller.

This is a useful thing which reduces the need for users to write their own code walker in certain kinds of advanced macros.

Perl 6 does[1], referenced directly from CLOS (from which a lot of other stuff was cribbed from as well).

1: https://docs.perl6.org/language/exceptions

You are basically stating that we should be doing both try/catch AND result/option at the same time, everywhere. That would get annoying fast.

Many people sooner or later have to spend an evening/night debugging serious issue affecting critical production system, discovering that system is left in inconsistent state after some corner case is throwing an exception that the code between it and the catch block didn't anticipate/handle correctly. And then they become emotionally invested.

> code between it and the catch block didn't anticipate/handle correctly

This sounds like a general errors handling issue that nor exceptions nor monadic errors types can prevent.

No language can fix mistakes, but in Rust if you have a() calling b() which calls c(), there is no way* that c can jump to a without any indication of it in b. You at least need to have `?` somewhere in b. I consider it a really good thing, among other advantages.

* panic + catch_unwind, but that's special and not meant or used in practice for error handling

Rust requires at compile-time that you handle each case.

I'd even prefer the golang way of error handling by `if err!= nil` over exceptions, treating errors as values is so much better

Hyperbole is lost on you, it seems.