3 ms·

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 beca

by 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

by mmstick 10y ago

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