5 ms·

Just curious, have you ever used any other modern languages that do not use exceptions for error handling? Most people who complain are just used to the excepti

Just curious, have you ever used any other modern languages that do not use exceptions for error handling? Most people who complain are just used to the exception way, but once you embrace returning errors out of functions, it really does feel like a massive improvement in terms of the paradigm.

CalChris 10y ago
How do you return failure for a bus error in Rust?
- Jweb_Guru 10y ago
  You can use signal handlers if you need to, but it's not like there's a good way to handle most bus errors in userspace to begin with. Anyway neither standard C nor standard C++ even spec out interrupt handling, and SIGBUS isn't a standard signal :P
  - CalChris 10y ago
    A signal handler (signal!(sig::ffi::Sig::BUS, test_bus);) will catch the bus error in userspace. You now need to communicate that caught exception to the offending fn. For that, you'll need setjmp() and longjmp(), something else that Rust lacks. If Rust is going to bill itself as a systems programming language, it needs these. I added them for my app: extern { #[link_name = "llvm.setjmp"] pub fn setjmp(a: *mut i8) -> i32; #[link_name = "llvm.longjmp"] pub fn longjmp(a: *mut i8, b: i32) -> (); } It took me awhile to figure this out (and it barely works). There's a cleaner way (adding a wrapper) that is even more work.
    - Jweb_Guru 10y ago
      > A signal handler will catch the bus error in userspace. Sure, but what I meant is that most of the time userspace programs have nothing interesting they can do with the bus error (and, as I noted, standard C does not actually provide this option anyway). Regardless there are existing signal handling libraries that aren't that hard to use in Rust (you now describe one in your post), so I'm not sure why you're pointing to that as "something... that Rust lacks." There's no way I'm aware of that setjmp / longjmp could possibly be integrated with safe Rust, but I agree that they should be available to unsafe code (in a way that doesn't require invoking llvm intrinsics).
    - sidlls 10y ago
      Whenever I see "systems programming language" in the context of Rust advocacy I've basically begun mentally substituting "programming at the applications/systems grey-area border". There's a lot of ambiguity about what "systems programming" really means, so I wouldn't say they're not using it correctly, but I've been getting the impression that your brand of systems programming isn't what they're targeting. And that's okay. There is a ton of space outside of that context, and still within the "systems" space that C and C++ could use a high quality competitor in, and Rust fits that bill nicely, in my view.
      - pcwalton 10y ago
        Rust is targeting all meanings of the word "systems programming". If you need some feature that Rust doesn't have, file an issue or write an RFC.
      - lifthrasiir 10y ago
        I think you have some point (especially for the definition of "systems programming"), but in my perspective Rust has a possibility [1] to encompass the largest possible meaning for systems programming. Here's why: Rust the language is really composed of two almost identical subsets, "safe" one and "unsafe". Safe Rust is what you will normally see, governed by normal safety rules and abstractions. Unsafe Rust is not what you will normally see, but still governed by safety rules and abstractions, only with an escape hatch. What I feel is that safe Rust covers the higher-level subset of "systems programming" (predictable performance, strong abstraction and safety), while unsafe Rust covers the lower-level subset of "systems programming" (excellent performance, near-complete control over everything). And still they are almost identical, so that the abstraction made in unsafe Rust is usable in safe Rust, and that's ideally how it covers the entirety of "systems programming"---the only border is the abstraction itself. Of course, provided that we have enough supply for appropriate abstractions (the community is trying hard with several promising results though). Rust programmers do like the safety guarantee of safe Rust and rarely talk about unsafe Rust, but I think unsafe Rust plays a large role in the possibility of Rust. It's much closer than the border between, say, "glue" languages and their implementation languages. We don't change the fact that we will sometimes have to bend the rules (it's probably impossible). Instead we let you bend the rules, but only when you are in the cage. And that cage is, while not immunable to every attack, really strong. [1] The advocacy naturally advocates for something's possibility and not for something's success. So it is still correct that Rust still lacks some solutions for existing problems, though it's not inherent.
soulbadguy 10y ago
Haskell is the last language i used without exceptions
- Jweb_Guru 10y ago
  Haskell has exceptions. So does Rust. People just prefer to use Either / Result (with good reason).
  - soulbadguy 10y ago
    Exception in Haskell ?
    - Jweb_Guru 10y ago
      Yeah. Try grabbing the head of an empty list, for instance. People for the most part don't like exceptions in Haskell, but that's not the same as the language not having them.
    - dbaupp 10y ago
      The `error` function is approximately `throw`. Catchable with: https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Exception.html#g:5 https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...
gorthol 10y ago
I work on several languages professionally being the only one without exceptions Go and I don't see how its idiotic pattern of checking the value returned after every single call is a massive improvement on anything except masochism.
- kixunil 10y ago
  I dislike Go's error handling too. Rust solved this neatly with question mark operator (previously implemented as try!() macro).
- leshow 10y ago
  Go's "error" system is nothing like Rusts. I personally find Go's terrible and boilerplate-y. Rust's uses algebraic types to make things checked at compile time and uses operators like `?` to give you expressiveness while removing the overhead and annoyance of manually checking everything. It is a huge improvement.

CalChris 10y ago

How do you return failure for a bus error in Rust?

Jweb_Guru 10y ago
You can use signal handlers if you need to, but it's not like there's a good way to handle most bus errors in userspace to begin with. Anyway neither standard C nor standard C++ even spec out interrupt handling, and SIGBUS isn't a standard signal :P
- CalChris 10y ago
  A signal handler (signal!(sig::ffi::Sig::BUS, test_bus);) will catch the bus error in userspace. You now need to communicate that caught exception to the offending fn. For that, you'll need setjmp() and longjmp(), something else that Rust lacks. If Rust is going to bill itself as a systems programming language, it needs these. I added them for my app: extern { #[link_name = "llvm.setjmp"] pub fn setjmp(a: *mut i8) -> i32; #[link_name = "llvm.longjmp"] pub fn longjmp(a: *mut i8, b: i32) -> (); } It took me awhile to figure this out (and it barely works). There's a cleaner way (adding a wrapper) that is even more work.
  - Jweb_Guru 10y ago
    > A signal handler will catch the bus error in userspace. Sure, but what I meant is that most of the time userspace programs have nothing interesting they can do with the bus error (and, as I noted, standard C does not actually provide this option anyway). Regardless there are existing signal handling libraries that aren't that hard to use in Rust (you now describe one in your post), so I'm not sure why you're pointing to that as "something... that Rust lacks." There's no way I'm aware of that setjmp / longjmp could possibly be integrated with safe Rust, but I agree that they should be available to unsafe code (in a way that doesn't require invoking llvm intrinsics).
  - sidlls 10y ago
    Whenever I see "systems programming language" in the context of Rust advocacy I've basically begun mentally substituting "programming at the applications/systems grey-area border". There's a lot of ambiguity about what "systems programming" really means, so I wouldn't say they're not using it correctly, but I've been getting the impression that your brand of systems programming isn't what they're targeting. And that's okay. There is a ton of space outside of that context, and still within the "systems" space that C and C++ could use a high quality competitor in, and Rust fits that bill nicely, in my view.
    - pcwalton 10y ago
      Rust is targeting all meanings of the word "systems programming". If you need some feature that Rust doesn't have, file an issue or write an RFC.
    - lifthrasiir 10y ago
      I think you have some point (especially for the definition of "systems programming"), but in my perspective Rust has a possibility [1] to encompass the largest possible meaning for systems programming. Here's why: Rust the language is really composed of two almost identical subsets, "safe" one and "unsafe". Safe Rust is what you will normally see, governed by normal safety rules and abstractions. Unsafe Rust is not what you will normally see, but still governed by safety rules and abstractions, only with an escape hatch. What I feel is that safe Rust covers the higher-level subset of "systems programming" (predictable performance, strong abstraction and safety), while unsafe Rust covers the lower-level subset of "systems programming" (excellent performance, near-complete control over everything). And still they are almost identical, so that the abstraction made in unsafe Rust is usable in safe Rust, and that's ideally how it covers the entirety of "systems programming"---the only border is the abstraction itself. Of course, provided that we have enough supply for appropriate abstractions (the community is trying hard with several promising results though). Rust programmers do like the safety guarantee of safe Rust and rarely talk about unsafe Rust, but I think unsafe Rust plays a large role in the possibility of Rust. It's much closer than the border between, say, "glue" languages and their implementation languages. We don't change the fact that we will sometimes have to bend the rules (it's probably impossible). Instead we let you bend the rules, but only when you are in the cage. And that cage is, while not immunable to every attack, really strong. [1] The advocacy naturally advocates for something's possibility and not for something's success. So it is still correct that Rust still lacks some solutions for existing problems, though it's not inherent.

soulbadguy 10y ago

Haskell is the last language i used without exceptions

Jweb_Guru 10y ago
Haskell has exceptions. So does Rust. People just prefer to use Either / Result (with good reason).
- soulbadguy 10y ago
  Exception in Haskell ?
  - Jweb_Guru 10y ago
    Yeah. Try grabbing the head of an empty list, for instance. People for the most part don't like exceptions in Haskell, but that's not the same as the language not having them.
  - dbaupp 10y ago
    The `error` function is approximately `throw`. Catchable with: https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-Exception.html#g:5 https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...

gorthol 10y ago

I work on several languages professionally being the only one without exceptions Go and I don't see how its idiotic pattern of checking the value returned after every single call is a massive improvement on anything except masochism.

kixunil 10y ago
I dislike Go's error handling too. Rust solved this neatly with question mark operator (previously implemented as try!() macro).
leshow 10y ago
Go's "error" system is nothing like Rusts. I personally find Go's terrible and boilerplate-y. Rust's uses algebraic types to make things checked at compile time and uses operators like `?` to give you expressiveness while removing the overhead and annoyance of manually checking everything. It is a huge improvement.