3 ms·

> Panics are recoverable You can't rely on this. Panics could just as easily abort your program. (By changing a flag on the compiler.)

quotemstr 10y ago
If you write a general purpose library, you have to make conservative assumptions and work either way. By the way: I am depressed as hell that the Rust people, knowing full well what went wrong in the C++ ecosystem, repeated the mistake of having an -fno-exceptions and thereby fragmentating the language.
- burntsushi 10y ago
  In C++, exceptions are a first class error handling mechanism. This is not the case in Rust, so it can't be the same mistake. Rust (and C++) are systems programming languages. Users must retain the ability to opt out of the cost of exceptions. The problem with C++ is that exceptions are a first class error handling mechanism. > If you write a general purpose library, you have to make conservative assumptions and work either way. If panics abort and they were our only error handling mechanism, then there is no other way to do error handling. > All of this because some people don't like exceptions On the one hand, you want people to understand your position. But on the other hand, you come off as implying the Rust designers (which includes the entire community) are a bunch of incompetent boobs that irrationally dismissed exceptions just because they "didn't like them." Do you see how these things conflict with each other? I'd suggest reconsidering your approach when engaging in discussion on this topic with others. As it stands now, you're extremely difficult to talk to.
  - quotemstr 10y ago
    I agree that it must be possible to use the language in a very low overhead, literal way. That's not most use, I think. Most applications can tolerate exceptions, so stdlib should have used exceptions to report errors. The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. If exceptions were the only way to report errors in stdlib, stdlib wouldn't have had to panic on errors --- or, rather, users would have come to expect these panics instead of treating them as a fatal, anomalous condition. The trade off seems wrong here --- you should be able to support stdlib and exceptions for clarity or !stdlib and !exceptions for full control, but I don't see a big case for stdlib and ! exceptions, but the way Rust is designed, everyone pays for the stdlib and !exceptions model. (And they have to care about exceptions anyway, but can't rely on them.) I think Rust's error handling is very poor design. I regret that this opinion coming across makes it difficult to have a conversation.
    - burntsushi 10y ago
      If your only error handling mechanism is exceptions and you disable exceptions because you can't bare the cost, then what are you left with? > The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. I don't agree. Just because I don't want to pay for exceptions doesn't mean I don't want, say, convenient platform abstractions over file systems or I/O. > I regret that this opinion The opinion that you don't like Rust's error handling isn't the problem. It's all of the insinuations you're making about the people who worked on it. You paint a picture of carelessness and irrationality, but that couldn't be further from the truth. The other problem is that exceptions vs. error values---aside from the performance or implementation implications---is a debate unto itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong. On the other hand, I'm trying to sit here and say that there are trade offs, but you don't want to acknowledge them.
      - quotemstr 10y ago
        What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong This debate was settled: we started out with error codes. We saw a generation of languages with exceptions --- Java, C++, CL with its condition system, Python, etc. arise in reaction to the problems with error codes. The current movement away from exceptions, which I think started with Go, feels like backsliding, especially because most of the justifications for error code primacy that I see either ignore the actual (instead of mythologized) costs of exceptions or claim that exceptional code is a hardship inconsistent with my experience. Now, it's possible that we should think of exceptions as just a failed experiment, but that view isn't consistent with the extreme utility I've seen in exception systems. Exceptions are so useful that people build them out of longjmp! Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) Still, exceptions in stdlib with an option for an exception free standalone system feels like the more appropriate trade-off. I understand that there are trade-offs everywhere, but this observation doesn't mean that I have to excuse what I see as very bad trade-offs.

quotemstr 10y ago

If you write a general purpose library, you have to make conservative assumptions and work either way. By the way: I am depressed as hell that the Rust people, knowing full well what went wrong in the C++ ecosystem, repeated the mistake of having an -fno-exceptions and thereby fragmentating the language.

burntsushi 10y ago
In C++, exceptions are a first class error handling mechanism. This is not the case in Rust, so it can't be the same mistake. Rust (and C++) are systems programming languages. Users must retain the ability to opt out of the cost of exceptions. The problem with C++ is that exceptions are a first class error handling mechanism. > If you write a general purpose library, you have to make conservative assumptions and work either way. If panics abort and they were our only error handling mechanism, then there is no other way to do error handling. > All of this because some people don't like exceptions On the one hand, you want people to understand your position. But on the other hand, you come off as implying the Rust designers (which includes the entire community) are a bunch of incompetent boobs that irrationally dismissed exceptions just because they "didn't like them." Do you see how these things conflict with each other? I'd suggest reconsidering your approach when engaging in discussion on this topic with others. As it stands now, you're extremely difficult to talk to.
- quotemstr 10y ago
  I agree that it must be possible to use the language in a very low overhead, literal way. That's not most use, I think. Most applications can tolerate exceptions, so stdlib should have used exceptions to report errors. The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. If exceptions were the only way to report errors in stdlib, stdlib wouldn't have had to panic on errors --- or, rather, users would have come to expect these panics instead of treating them as a fatal, anomalous condition. The trade off seems wrong here --- you should be able to support stdlib and exceptions for clarity or !stdlib and !exceptions for full control, but I don't see a big case for stdlib and ! exceptions, but the way Rust is designed, everyone pays for the stdlib and !exceptions model. (And they have to care about exceptions anyway, but can't rely on them.) I think Rust's error handling is very poor design. I regret that this opinion coming across makes it difficult to have a conversation.
  - burntsushi 10y ago
    If your only error handling mechanism is exceptions and you disable exceptions because you can't bare the cost, then what are you left with? > The people who can't tolerate exceptions are the same ones who want precise machine control and who probably don't want stdlib either. I don't agree. Just because I don't want to pay for exceptions doesn't mean I don't want, say, convenient platform abstractions over file systems or I/O. > I regret that this opinion The opinion that you don't like Rust's error handling isn't the problem. It's all of the insinuations you're making about the people who worked on it. You paint a picture of carelessness and irrationality, but that couldn't be further from the truth. The other problem is that exceptions vs. error values---aside from the performance or implementation implications---is a debate unto itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong. On the other hand, I'm trying to sit here and say that there are trade offs, but you don't want to acknowledge them.
    - quotemstr 10y ago
      What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong This debate was settled: we started out with error codes. We saw a generation of languages with exceptions --- Java, C++, CL with its condition system, Python, etc. arise in reaction to the problems with error codes. The current movement away from exceptions, which I think started with Go, feels like backsliding, especially because most of the justifications for error code primacy that I see either ignore the actual (instead of mythologized) costs of exceptions or claim that exceptional code is a hardship inconsistent with my experience. Now, it's possible that we should think of exceptions as just a failed experiment, but that view isn't consistent with the extreme utility I've seen in exception systems. Exceptions are so useful that people build them out of longjmp! Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) Still, exceptions in stdlib with an option for an exception free standalone system feels like the more appropriate trade-off. I understand that there are trade-offs everywhere, but this observation doesn't mean that I have to excuse what I see as very bad trade-offs.