Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You are saying this would not have happened in a C release build where asserts define to nothing?

Wonder why these old grey beards chose to go with that.





I am one of those old grey beards (or at least, I got started shipping C code in the 1990s), and I'd leave asserts in prod serverside code given the choice; better that than a totally unpredictable error path.

> You are saying this would not have happened in a C release build where asserts define to nothing?

Afaik, Go and Java are the only languages that make you pause and explicitly deal with these exceptions.


And rust, but they chose to panic on the error condition. Wild.

> And rust, but they chose to panic on the error condition. Wild.

unwrap() implicitly panic-ed, right?


I don't think "implicitly panicked" is an accurate description since unwrap()'s entire reason for existing is to panic if you unwrap an error condition. If you use unwrap(), you're explicitly opting into the panicking behavior.

I suppose another way to think about it is that Result<T, E> is somewhat analogous to Java's checked exceptions - you can't get the T out unless you say what to do in the case of the E/checked exception. unwrap() in this context is equivalent to wrapping the checked exception in a RuntimeException and throwing that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: