4 ms·

By crashes we mean panics. We still panic in various places in the code when something goes wrong.

tinco 10y ago
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.
- Morgawr 10y ago
  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.
  - majewsky 10y ago
    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).
- Manishearth 10y ago
  Heh. Earlier in this thread, someone did indeed find a bug in our image loading: https://news.ycombinator.com/item?id=12014108 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 :)
- gsnedders 10y ago
  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.
- AlisdairO 10y ago
  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.
  - tedmiston 10y ago
    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.
  - Manishearth 10y ago
    unimplemented!() exists
    - AlisdairO 10y ago
      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 :-)

tinco 10y ago

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.

Morgawr 10y ago
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.
- majewsky 10y ago
  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).
Manishearth 10y ago
Heh. Earlier in this thread, someone did indeed find a bug in our image loading: https://news.ycombinator.com/item?id=12014108 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 :)
gsnedders 10y ago
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.
AlisdairO 10y ago
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.
- tedmiston 10y ago
  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.
- Manishearth 10y ago
  unimplemented!() exists
  - AlisdairO 10y ago
    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 :-)