3 ms·

> there will always be a case where you forget to propagate an error you got Not if the ecosystem supports Result types a la Rust (and others). You don't get

> there will always be a case where you forget to propagate an error you got Not if the ecosystem supports Result types a la Rust (and others). You don't get to access the return value unless you deal with handling the error first.

jcelerier 7y ago
> You don't get to access the return value unless you deal with handling the error first. Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site, so from what I could see, either people end up doing nothing and "abandoning" the error (bad) or panicking (worse). It's better to just let the error go transparently so that if someone actually can do something meaningful upper in the call stack, it's possible. source : https://github.com/search?l=Rust&q=panic&type=Code https://github.com/search?l=Rust&q=panic&type=Code
- deleted 7y ago
  [deleted]
- steveklabnik 7y ago
  Hm, we must read very different Rust code. ? is even easier than a panic. And that search has a ton of false positives: both in general, as well as "unwrap" being the more common way to get a Result to panic.
  - jcelerier 7y ago
    c'mon... $ cd servo/components $ rg -F 'panic!' | wc -l 276 Likely a fair amount is justifiable, but things like this ? https://github.com/servo/servo/blob/master/components/script/dom/bindings/structuredclone.rs#L74 https://github.com/servo/servo/blob/master/components/script... or this https://github.com/servo/servo/blob/master/components/gfx/platform/freetype/font_list.rs#L96 https://github.com/servo/servo/blob/master/components/gfx/pl... ? that's a really strong code smell (or at least doing a similar thing in a C++ program, e.g. calling abort() / SIGTRAP, would be, even with a signal handler, a really really really long discussion in code review)
    - steveklabnik 7y ago
      loc in that same directory says 289958 lines of Rust code, that is a ratio of 0.00095186199. That is pretty small. 175 unwraps, which I am actually shocked is smaller than panics. And yes, I do think that both of these are pretty justifiable: both of these are effectively assertions, which is not unheard of in C either.
- jjnoakes 7y ago
  People may do it wrong in rust but I personally like that rust gives me the tools to handle errors in my preferred way: explicitly passing them up the stack with minimal verbosity (using ?) or explicitly having to handle them in some way. I don't like verbose error checking on every function call which is ugly and which I might forget to pass up (c-style) and I don't like exceptions which aren't expicit and which I might forget to handle locally if I wanted to.
- jnbiche 7y ago
  > Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site If you're working with a `Result` type, you can pass the wrapped value up to wherever you want to/can handle it. Either way, you have to handle it. And the type checker ensures that you do. Typed error checking as available in Rust, Scala, OCaml, ReasonML, Swift, Haskell etc, etc is a far, far better solution than exceptions. I've worked on large code bases with both. There's no comparison. Even Java's checked exceptions are far, far better than unchecked exceptions like C++. People complain, but it's shitty coding practice not to properly handle a function that can throw (and I speak as someone who's done this and gotten badly bit by it a dozen times before I wised up). If there's absolutely no recovery possible from an error, then yes, an exception may be acceptable. Otherwise, error values, which can be type checked, are the way to go if offered in your language.

jcelerier 7y ago

> You don't get to access the return value unless you deal with handling the error first. Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site, so from what I could see, either people end up doing nothing and "abandoning" the error (bad) or panicking (worse). It's better to just let the error go transparently so that if someone actually can do something meaningful upper in the call stack, it's possible. source : https://github.com/search?l=Rust&q=panic&type=Code https://github.com/search?l=Rust&q=panic&type=Code

deleted 7y ago
[deleted]
steveklabnik 7y ago
Hm, we must read very different Rust code. ? is even easier than a panic. And that search has a ton of false positives: both in general, as well as "unwrap" being the more common way to get a Result to panic.
- jcelerier 7y ago
  c'mon... $ cd servo/components $ rg -F 'panic!' | wc -l 276 Likely a fair amount is justifiable, but things like this ? https://github.com/servo/servo/blob/master/components/script/dom/bindings/structuredclone.rs#L74 https://github.com/servo/servo/blob/master/components/script... or this https://github.com/servo/servo/blob/master/components/gfx/platform/freetype/font_list.rs#L96 https://github.com/servo/servo/blob/master/components/gfx/pl... ? that's a really strong code smell (or at least doing a similar thing in a C++ program, e.g. calling abort() / SIGTRAP, would be, even with a signal handler, a really really really long discussion in code review)
  - steveklabnik 7y ago
    loc in that same directory says 289958 lines of Rust code, that is a ratio of 0.00095186199. That is pretty small. 175 unwraps, which I am actually shocked is smaller than panics. And yes, I do think that both of these are pretty justifiable: both of these are effectively assertions, which is not unheard of in C either.
jjnoakes 7y ago
People may do it wrong in rust but I personally like that rust gives me the tools to handle errors in my preferred way: explicitly passing them up the stack with minimal verbosity (using ?) or explicitly having to handle them in some way. I don't like verbose error checking on every function call which is ugly and which I might forget to pass up (c-style) and I don't like exceptions which aren't expicit and which I might forget to handle locally if I wanted to.
jnbiche 7y ago
> Well, that's exactly what I was referring to. 80% of the time you don't / can't know what to do with the error at a given call site If you're working with a `Result` type, you can pass the wrapped value up to wherever you want to/can handle it. Either way, you have to handle it. And the type checker ensures that you do. Typed error checking as available in Rust, Scala, OCaml, ReasonML, Swift, Haskell etc, etc is a far, far better solution than exceptions. I've worked on large code bases with both. There's no comparison. Even Java's checked exceptions are far, far better than unchecked exceptions like C++. People complain, but it's shitty coding practice not to properly handle a function that can throw (and I speak as someone who's done this and gotten badly bit by it a dozen times before I wised up). If there's absolutely no recovery possible from an error, then yes, an exception may be acceptable. Otherwise, error values, which can be type checked, are the way to go if offered in your language.