5 ms·

I would be downright appalled if Rust were to start promoting exceptions. It's an anti-feature.

• soulbadguy 10y ago
  Being this emotionally invested in a feature, really is unprofessional...
  • mmstick 10y ago
    Using exceptions would be unprofessional. If someone were to use exceptions, then all of my carefully crafted error-handling routines would go up in flames because someone's library decided not to use an algebraic data type for conveying error messages across boundaries. It's bad enough that C libraries can suffer catastrophic failures bringing the entire stack down. I want a consistent error-handling strategy, and pattern matching is the best method of clearly displaying intents and possible downfalls.
    • soulbadguy 10y ago
      > Using exceptions would be unprofessional. Unless it happens to be the best tools for the particular scenario... > then all of my carefully crafted error-handling routines would go up in flames No just sandbox the code inside a try catch... > pattern matching is the best method of clearly displaying intents and possible downfalls. You are stating an opinions as a fact here.
      • mmstick 10y ago
        You are basically stating that we should be doing both try/catch AND result/option at the same time, everywhere. That would get annoying fast.
      • hyperpape 10y ago
        > No just sandbox the code inside a try catch... This works fine if it's just a matter of rolling back a database transaction or releasing file handles (b/c someone else is doing all the work for you). But if you have more complicated invariants, your try catch has to handle restoring those invariants, no matter what path your code took.
        • lokedhs 10y ago
          I'd recommend taking a look at Common Lisps condition system, which does exceptions right. The most important feature is that catch blocks are executed before the stack is unwond, providing the ability for a handler to signal back to the context where the error occurred how it should be handled. It's sad that no other languages implement this and instead simply decide that exceptions are bad.
          • steveklabnik 10y ago
            Fun trivia: Rust had conditions! Nobody used them, so they were removed.
            • lokedhs 9y ago
              That sounds short-sighted to me. Even in Lisp restarts (i.e. the feature that allows a handler to communicate back to the point where the exception was thrown) aren't used that often, but when they are, they are incredibly valuable.
              • kazinator 9y ago
                In TXR Lisp, a continuable exception occurs every time you see a warning about something in the code, like an unbound variable. It is intercepted higher up and automatically continued. The code expander has an entry point which allows the caller to be informed about what variables and functions are free in a block of code. The implementation of this entry point works by intercepting warning exceptions about unbound symbols, and accumulating them in in lists, which are then returned to the caller. This is a useful thing which reduces the need for users to write their own code walker in certain kinds of advanced macros.
          • kbenson 10y ago
            Perl 6 does[1], referenced directly from CLOS (from which a lot of other stuff was cribbed from as well). 1: https://docs.perl6.org/language/exceptions https://docs.perl6.org/language/exceptions
  • dpc_pw 10y ago
    Many people sooner or later have to spend an evening/night debugging serious issue affecting critical production system, discovering that system is left in inconsistent state after some corner case is throwing an exception that the code between it and the catch block didn't anticipate/handle correctly. And then they become emotionally invested.
    • soulbadguy 10y ago
      > code between it and the catch block didn't anticipate/handle correctly This sounds like a general errors handling issue that nor exceptions nor monadic errors types can prevent.
      • dpc_pw 10y ago
        No language can fix mistakes, but in Rust if you have a() calling b() which calls c(), there is no way* that c can jump to a without any indication of it in b. You at least need to have `?` somewhere in b. I consider it a really good thing, among other advantages. * panic + catch_unwind, but that's special and not meant or used in practice for error handling
      • mmstick 10y ago
        Rust requires at compile-time that you handle each case.
  • mkawia 10y ago
    I'd even prefer the golang way of error handling by `if err!= nil` over exceptions, treating errors as values is so much better
  • leshow 10y ago
    Hyperbole is lost on you, it seems.