To clarify, a panic in rust is the result of an unhandled exception. Usually this is due to laziness rather than a real bug. For example Servo might encounter an IMG tag, start to load the body. The result might be stored in an option because something could have gone wrong during loading (peer disconnected etc.) but the developer didn't feel like implementing robust image handling that day and instead called .expect to extract the image. This throws a panic and exits the application if the image is not there.

This is just a hypothetical example, I bet image loading is one of the things Servo does fine. Just to give you an idea of when Rust might panic.

Heh.

Earlier in this thread, someone did indeed find a bug in our image loading: https://news.ycombinator.com/item?id=12014108

We were basically panicking when an invalid URL was given to us. There was a comment there noting this -- which means that this was probably written when it wasn't so important to handle all the cases, and more important to handle some cases so that we can test out various ideas. We're still sort of in that stage, and you may see other comments like this throughout the code :)

I do things like this all the time in Haskell when quickly prototyping new code and then swiftly kick myself because of it. Safe languages are nice, but there's really no way to prevent a developer from saying "Yeah fuck it, this case will never happen anyway" and then calling a fromJust on a Maybe monad which turns out was a Nothing and throws a runtime exception.

Well, there is a way: Don't allow partial functions like fromJust or head. But a) it's going to make prototyping so tedious that no one will bother using this hypothetical language, and b) there are problems that you just cannot solve without partial functions (e.g. foldl1).

And importantly, a panic is not a result of a memory safety bug, and those are the crashes (with their potential security risks) that Rust is aiming to get rid of.

It would be quite nice if there was a synonym for expect (say unimplemented_expect) that meant 'I haven't bothered to implement the proper error handling yet' rather than 'error handling shouldn't be required'. That would really enhance auditability of in-progress code.

Python has a nice built-in exception for this: NotImplementedError. It's intended usage was related to abstract base classes, but it's taken on this secondary use case recently.

unimplemented!() exists

Yeah, I use that, but it obviously requires more work than a simple unwrap or expect, so the temptation is to just use those and think you'll remember to flesh it out later :-)