8 ms·

I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being awar

I made this argument in the talk: the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. Many c++ projects disable exceptions entirely. Writing "exception safe" code is tricky and non-obvious. Functions which should be guaranteed to never fail often can throw std::bad_alloc. Try-catch syntax forces incorrect nesting. Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs.

bluejekyll 8y ago
> Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs. Out of curiosity, have you compared this to Rust’s backtrace mechanism? I’d be interested in the perf difference, if it’s available.
- dbaupp 8y ago
  Rust's panics and their backtrackes are essentially the same as C++ exceptions.
  - bluejekyll 8y ago
    I wasn’t actually thinking about panic, but the associated optional backtrace in Error types with Failure, for example: https://docs.rs/failure/0.1.3/failure/ https://docs.rs/failure/0.1.3/failure/
    - dbaupp 8y ago
      Ah, I see. Looking at the source code https://docs.rs/crate/failure/0.1.3/source/src/backtrace/internal.rs https://docs.rs/crate/failure/0.1.3/source/src/backtrace/int..., "failure" uses https://docs.rs/backtrace/0.3.9/backtrace/struct.Backtrace.html#method.new_unresolved https://docs.rs/backtrace/0.3.9/backtrace/struct.Backtrace.h... which is the callstack at a single point, not a trace of how an error was propagated.
Ace17 8y ago
> the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. That's the whole point of exceptions.
- gameswithgo 8y ago
  there are a lot of points in language design that people don't all agree on, or that might be appropriate for one kind of work and not for another.
christophilus 8y ago
Hey. Thanks for making Zig. I’m glad it’s moving forward. Don’t let all the negative comments get you down. It happens to every language author. (See some of the nasty comments on Elm, Clojure, Go, Jai, etc.) I, for one, am happy that all of these languages exist, even those that don’t scratch my itches.
- electrograv 8y ago
  Completely agree — Zig and it’s design philosophy is absolutely fantastic for its domin, and I’m very glad it exists. I like Rust and other modern languages too, but Zig strikes me as just about the best possible contender for a true C/C++ replacement (due to seamless interop, and a very practical and well designed simple language core — as opposed to the complexity of something like Rust, for example).
platz 8y ago
> the only problem with exception-based handling is the lack of explicitness - It's too easy to call functions without being aware of the set of possible errors. i.e. checked-exceptions?
- marmaduke 8y ago
  yep! there was a sort of epiphany for me, the first I wrote Java, from Python, when I realized that I can be sure that my code could handle anything the callee could throw at it.
  - sqrt17 8y ago
    There are still plenty of exceptions that are unchecked, i.e. subtypes of RuntimeException, which do not have to be declared on the callee. As well as people who think it's a good idea to throw instances of Exception and just tack a "throws Exception" on their methods.
    - loeg 8y ago
      Right — that's a failing of Java the language; not the concept of checked exceptions. At least one problem with Java's exception model that Zig does not have is that some exceptions are "unchecked."
      - Jach 8y ago
        The 'failing' of checked exceptions comes from essentially being forced to couple the type signatures of your methods' successful results with their error results. A more explicit way to do this is with Optional/Either types, and now you don't need the checked exceptions feature nor need to get people to remember to check for a global errno or some other data convention like an empty string / null. There's a lot of boilerplate though, just like with checked exceptions. I prefer a more decoupled/late-binding approach to error handling; so far Common Lisp does it the best I've seen.[0] The key insight CL people had was that often in the face of an error, you need help from somewhere away from your local context to figure out how to resolve it, but then for many cases, you want to return back to where the error has occurred and take the resolution path with your local context. In other languages that automatically unwind the stack to the exception handler, it's too late. [0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...
dbaupp 8y ago
Link for convenience: https://ziglang.org/documentation/master/#Error-Return-Traces https://ziglang.org/documentation/master/#Error-Return-Trace...
wvenable 8y ago
> It's too easy to call functions without being aware of the set of possible errors. But that's entirely fine! Programmers are far too obsessed with exactly which functions trigger which errors when it absolutely doesn't matter. All you need to know is what errors you can handle and where in the code you can handle them. If there is a network exception and can recover and retry it at the start of the operation, it literally doesn't matter which of the thousands of functions up the call stack could have possibly triggered it. The only thing you need to know is the top-level network exception and where your network processing code starts. And if you can't handle a network error, it literally doesn't matter if one was triggered. The best you can do is abort and record a really good stack trace for that type of error.
- IanCal 8y ago
  > All you need to know is what errors you can handle and where in the code you can handle them. Surely also what errors can occur. Can the network using library throw disk IO errors? Permissions errors? Maybe it handles all the network errors internally to the library and I don't need to deal with those at all.
  - wvenable 8y ago
    How do you handle those other errors though? If there is a disk I/O error, you're basically done. Permission errors, same thing. You report, abort, maybe retry. You don't really need to know in the specific what kinds of errors can occur. If it's possible to recover from an exceptional situation, it's only useful to know if that situation is possible so you can avoid writing code you don't need to. But there wouldn't be any harm in writing an exception handler for an exception that can't happen except for that wasted effort.
    - IanCal 8y ago
      Well it depends on what I'm doing and why the errors might be thrown right? Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)? Whether I retry on network errors can depend on what the error is - if the end service is responding saying my call is invalid for certain reasons there can be a good case to just die immediately rather than slowly backing off trying repeatedly in vain. The flip side of this is I shouldn't need to worry about exceptions that cannot be thrown. When you say all you need to know is what you can handle and where, that list must be a subset of the possible list of things that can be thrown. There's no point worrying about whether I should be retrying something due to network faults if it never uses the network to begin with.
otabdeveloper2 8y ago
> It's too easy to call functions without being aware of the set of possible errors. Yes, and that's a very good thing. > Many c++ projects disable exceptions entirely. Yes, and they're objectively wrong. > Writing "exception safe" code is tricky and non-obvious. The word 'exception' here is redundant.
- tjoff 8y ago
  > The word 'exception' here is redundant. Exceptions make it much harder.
tinus_hn 8y ago
Many languages have the possible exceptions as part of the function signature so you can't call a function without either handling, converting or passing any exceptions you may receive. It's a drag though.

bluejekyll 8y ago

> Related: Only zig has fast errors with traces. Other languages have no traces or a high performance cost. Look up error return traces in the docs. Out of curiosity, have you compared this to Rust’s backtrace mechanism? I’d be interested in the perf difference, if it’s available.

dbaupp 8y ago
Rust's panics and their backtrackes are essentially the same as C++ exceptions.
- bluejekyll 8y ago
  I wasn’t actually thinking about panic, but the associated optional backtrace in Error types with Failure, for example: https://docs.rs/failure/0.1.3/failure/ https://docs.rs/failure/0.1.3/failure/
  - dbaupp 8y ago
    Ah, I see. Looking at the source code https://docs.rs/crate/failure/0.1.3/source/src/backtrace/internal.rs https://docs.rs/crate/failure/0.1.3/source/src/backtrace/int..., "failure" uses https://docs.rs/backtrace/0.3.9/backtrace/struct.Backtrace.html#method.new_unresolved https://docs.rs/backtrace/0.3.9/backtrace/struct.Backtrace.h... which is the callstack at a single point, not a trace of how an error was propagated.

Ace17 8y ago

> the only problem with exception-based handling is the lack of explicitness. It's too easy to call functions without being aware of the set of possible errors. That's the whole point of exceptions.

gameswithgo 8y ago
there are a lot of points in language design that people don't all agree on, or that might be appropriate for one kind of work and not for another.

christophilus 8y ago

Hey. Thanks for making Zig. I’m glad it’s moving forward. Don’t let all the negative comments get you down. It happens to every language author. (See some of the nasty comments on Elm, Clojure, Go, Jai, etc.) I, for one, am happy that all of these languages exist, even those that don’t scratch my itches.

electrograv 8y ago
Completely agree — Zig and it’s design philosophy is absolutely fantastic for its domin, and I’m very glad it exists. I like Rust and other modern languages too, but Zig strikes me as just about the best possible contender for a true C/C++ replacement (due to seamless interop, and a very practical and well designed simple language core — as opposed to the complexity of something like Rust, for example).

platz 8y ago

> the only problem with exception-based handling is the lack of explicitness - It's too easy to call functions without being aware of the set of possible errors. i.e. checked-exceptions?

marmaduke 8y ago
yep! there was a sort of epiphany for me, the first I wrote Java, from Python, when I realized that I can be sure that my code could handle anything the callee could throw at it.
- sqrt17 8y ago
  There are still plenty of exceptions that are unchecked, i.e. subtypes of RuntimeException, which do not have to be declared on the callee. As well as people who think it's a good idea to throw instances of Exception and just tack a "throws Exception" on their methods.
  - loeg 8y ago
    Right — that's a failing of Java the language; not the concept of checked exceptions. At least one problem with Java's exception model that Zig does not have is that some exceptions are "unchecked."
    - Jach 8y ago
      The 'failing' of checked exceptions comes from essentially being forced to couple the type signatures of your methods' successful results with their error results. A more explicit way to do this is with Optional/Either types, and now you don't need the checked exceptions feature nor need to get people to remember to check for a global errno or some other data convention like an empty string / null. There's a lot of boilerplate though, just like with checked exceptions. I prefer a more decoupled/late-binding approach to error handling; so far Common Lisp does it the best I've seen.[0] The key insight CL people had was that often in the face of an error, you need help from somewhere away from your local context to figure out how to resolve it, but then for many cases, you want to return back to where the error has occurred and take the resolution path with your local context. In other languages that automatically unwind the stack to the exception handler, it's too late. [0] http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...

dbaupp 8y ago

Link for convenience: https://ziglang.org/documentation/master/#Error-Return-Traces https://ziglang.org/documentation/master/#Error-Return-Trace...

wvenable 8y ago

> It's too easy to call functions without being aware of the set of possible errors. But that's entirely fine! Programmers are far too obsessed with exactly which functions trigger which errors when it absolutely doesn't matter. All you need to know is what errors you can handle and where in the code you can handle them. If there is a network exception and can recover and retry it at the start of the operation, it literally doesn't matter which of the thousands of functions up the call stack could have possibly triggered it. The only thing you need to know is the top-level network exception and where your network processing code starts. And if you can't handle a network error, it literally doesn't matter if one was triggered. The best you can do is abort and record a really good stack trace for that type of error.

IanCal 8y ago
> All you need to know is what errors you can handle and where in the code you can handle them. Surely also what errors can occur. Can the network using library throw disk IO errors? Permissions errors? Maybe it handles all the network errors internally to the library and I don't need to deal with those at all.
- wvenable 8y ago
  How do you handle those other errors though? If there is a disk I/O error, you're basically done. Permission errors, same thing. You report, abort, maybe retry. You don't really need to know in the specific what kinds of errors can occur. If it's possible to recover from an exceptional situation, it's only useful to know if that situation is possible so you can avoid writing code you don't need to. But there wouldn't be any harm in writing an exception handler for an exception that can't happen except for that wasted effort.
  - IanCal 8y ago
    Well it depends on what I'm doing and why the errors might be thrown right? Is it something I can let the user retry if they know what's happening (e.g. IO error because the output folder doesn't exist)? Whether I retry on network errors can depend on what the error is - if the end service is responding saying my call is invalid for certain reasons there can be a good case to just die immediately rather than slowly backing off trying repeatedly in vain. The flip side of this is I shouldn't need to worry about exceptions that cannot be thrown. When you say all you need to know is what you can handle and where, that list must be a subset of the possible list of things that can be thrown. There's no point worrying about whether I should be retrying something due to network faults if it never uses the network to begin with.

otabdeveloper2 8y ago

> It's too easy to call functions without being aware of the set of possible errors. Yes, and that's a very good thing. > Many c++ projects disable exceptions entirely. Yes, and they're objectively wrong. > Writing "exception safe" code is tricky and non-obvious. The word 'exception' here is redundant.

tjoff 8y ago
> The word 'exception' here is redundant. Exceptions make it much harder.

tinus_hn 8y ago

Many languages have the possible exceptions as part of the function signature so you can't call a function without either handling, converting or passing any exceptions you may receive. It's a drag though.