> > Exceptions don't exist > > They're called panics.

Nope.

https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

It's non-local control flow with deterministic unwinding and defined stop points. It's an exception system.

Sure, it's not "recommended", but recommendations don't define semantics.

I'd say they do—a Rust user will never encounter a panic from a reasonable library that they're expected to catch.

If hypothetical unreasonable libraries are in scope, they can just open /proc/self/mem for writing (in safe Rust!) and violate memory safety, and that's not an argument that Rust isn't memory safe. So why should hypothetical unreasonable libraries be an argument that Rust has exceptions?

Because the language doesn't define what happens if you write to memory behind the runtime's back. It _does_ define, in detail, what occurs on panic. It's a legal thing to do. That some consider panicing in bad taste or whatever does not change the fact that panic is a supported feature of the language.

It also defines that it may abort, and so culturally, people use them for only what’s intended, as otherwise, it limits your audience.

> Any sort of polymorphism opens you up to the possibility that code that's written to take abstract type A, implemented concretely in B and C, implicitly expects a B and blows up when it gets a C. Rust doesn't solve this problem.

Can you explain this? Do you mean that the type C does not correctly implement A? Do you mean something that expects a specific value from a methid in A that only B will return? Both of those, while possible just seem like a complaint of "X doesn't prevent me from purposely breaking it".

One example is something like enum A { B, C }: a function might have a precondition that it requires an A::B, and crashes/misbehaves when given an A::C. In Rust, this can be seen in Option::unwrap (requires a Some, panicking if given a None). Technically this is the same sort of thing as in Java, but, at least to me, it seems different/more easily controlled.

Unwrap is essentially asking for it to fail under that condition, so that's not exactly broken.

Unwrap should always be suspect. It's easy to turn it into a pattern matcher instead, which explicitly forces you to hand the none case.

I'm not saying you're wrong, but I don't think it's an example of an error created by a polymorphic type. (Instances of the same type can do this as well.)

One can look at Option<T> as an interface/base class that can be satisfied by a T or by (). Indeed, in Java-style languages, one occasionally sees implementations that have an Option abstract base class, with two subclasses, Some and None. Both enums and subclassing are forms of polymorphism, the main conceptual difference is the polymorphism being closed or open (respectively). The fact that Rust adds extra layers of types/syntax on top of the raw polymorphism is syntactic sugar, just a disguise.

One could actually even express the Option concept as a trait, with manual downcasts:

  trait OptionLike {
      type Contained;
      fn is_some(self) -> bool;
      fn as_some(self) -> Some<Self::Contained>;
  }
  struct Some<T> { value: T }
  impl<T> OptionLike for Some<T> { ... }
  struct None<T> { _phantom: ...<T> }
  impl<T> OptionLike for None<T> { ... }

Under this scheme, Option<T> is expressed as a trait object like Box<OptionLike<Contained=T>>, and the whole thing looks a lot more like the OOP/subclassing approach.

In any case, the fact that unwrap is clearly documented to fail on the None case is orthogonal: it's an invariant about the (sub)types of it's arguments that isn't expressed in the signature.

See above about panics and exceptions; just because they’re similar doesn’t mean they’re the same.

I agree Rust doesn’t solve all bugs.