[native_samples]

Actually, up the stack is usually the only place that knows how to handle the error. For instance sometimes dumping to stderr is the right thing to do, other times logging it, other times displaying a generic crash GUI, sometimes display a customized UI. There may also be times when the exception can be handled in a better way, with fallbacks for example.

The Rust/Go approach always makes me laugh. Normally in engineering or anything where reliability matters, panicking is understood to be a bad thing to do and people go through extensive training to ensure they don't do it. Somehow these language communities decided that panicking and giving up on the spot is a smart behaviour.

[jeddy3]

> Somehow these language communities decided that panicking and giving up on the spot is a smart behaviour.

Oh, come on, that's a straw man.

Just because panic! exists as a "abort-program-with-a-message", does not mean it's somehow encouraged above using idiomatic error handling.

Just as you can do the same thing in languages with exceptions. Sometimes exiting the program is the right thing to do.

[native_samples]

Panic is idiomatic error handling. Take something as basic as indexing into a list. Get it wrong and Rust will panic.

Sometimes exiting the program is the right thing to do.

Yes, but it's very rare that the code where something went wrong is in the position to decide that. The survival of the entire process is not a decision to delegate to every possible line of code or library author.

Consider a very common case where I benefit from exceptions every day - my IDE. IntelliJ hosts a bazillion plugins, of varying quality. These plugins like to do very complex analysis on sometimes broken and incoherent snippets of code, that may be in the process of being edited. In other words it's a nightmare to correctly predict everything that can go wrong.

Not surprisingly, sometimes these plugins crash. And you know what? It doesn't matter. A lot of the code is just providing optional quality-of-life features like static analysis. If one of them goes wrong, IntelliJ looks at the exception and figures out which plugin is likely to blame, it examines the type of error and maybe gathers editor context, it can report it easily to a central server that then groups and aggregates exceptions based on stack traces. Meanwhile as a user, it doesn't bother me because it's fine to just not have that analysis show up in the editor.

If every time an IDE plugin encountered an unexpected situation it aborted the entire process it'd be insane. The plugin ecosystem could never scale that way. People would be afraid of installing/upgrading plugins and that in turn would discourage people from writing them or adding features to them.

[super_flanker]

> If every time an IDE plugin encountered an unexpected situation it aborted the entire process it'd be insane.

What if a plugin developer used `System.exit(-1)` in their catch block. How's Intellij going to handle that?

A very popular eclipse plugin did this in past and would bring down the entire IDE when a particular exception happened.

[native_samples]

In reality nothing does that because, well, why would you when you have good exceptions? But even so, Java has a way to block that using the SecurityManager. Now they are deprecating the SecurityManager "how do I stop code calling System.exit" is one of the use cases they're planning replacements for.

[super_flanker]

I'm sure there would still be ways to bring the entire process to halt(for example, spawn thousands of threads with infinite loop). My point is just because a bad developer wrote bad code doesn't mean that a tradeoff chosen for a language design is necessarily bad.

[native_samples]

In reality it's very hard to accidentally write an infinite loop that spawns threads. There's no idiom that would lead to such a pattern and I can't recall ever encountering such a bug in the wild.

Yes, in theory, there are all sorts of ways you can still trash the process with bad code. But in practice, the sorts of bugs that programmers really make in GC-d memory-safe languages are the ones that don't. So, exception based error handling really does come in very useful and Rust probably got it wrong here.

[bjarneh]

> The survival of the entire process is not a decision to delegate to every possible line of code or library author.

Stated like that, who can really disagree?

I remember when I was writing a bunch of Go when the language was still very new (2009 - 2011). One of the most popular use cases for the language was making websites. All sorts of unexpected problems caused the entire website to go down, due to unexpected panics here and there. The suggested solution from the Go team was to just restart the web-server whenever it was killed by a panic. Surely that cannot be the best way to do it..

[chlorion]

>Panic is idiomatic error handling. Take something as basic as indexing into a list. Get it wrong and Rust will panic.

This is not really true. If you are indexing into something that may fail you use the `get` method which returns an `Option` if the index is out of bounds. The index operator is just a shorthand for `v.get(i).unwrap()` pretty much.

https://doc.rust-lang.org/std/primitive.slice.html#method.ge...

[native_samples]

Yes, but the problem is that very often a programmer "knows" an index operation can't fail because they haven't thought of a case where it is a different size, or code gets refactored and assumptions are invalidated, etc.

The panic mentality comes from people who have spent most of their life writing C++, in which if anything goes wrong like an out of bounds index, memory might be corrupted in arbitrary ways, and in which you don't have a GC to clean up after you. Writing exception safe code is much easier in type safe GCd languages, and many programming errors end up being recoverable.