3 ms·

But why? Most modern languages try to get rid of exceptions (Go, Kotlin, Rust).

Genbox 4y ago
Kotlin does have exceptions[1] [1] https://kotlinlang.org/docs/exceptions.html#java-interoperability https://kotlinlang.org/docs/exceptions.html#java-interoperab...
- switchbak 4y ago
  They said "try to get rid of", which to me is akin to de-emphasizing. Of course you'd have to deal with exceptions since you're running on the JVM and want to Interop with Java code, that doesn't mean it's idiomatic code.
jallmann 4y ago
Golang has panic / recover / defer which are functionally similar to exceptions. It's actually a fun exercise to implement a pseudo-syntax for try/catch/finally in terms of those primitives.
- makapuf 4y ago
  Go has exceptions but its definitely not advised to use those as an error mechanism. Recover is really a last chance effort for recovery, not a standard error catching method.
  - brigandish 4y ago
    That's why they're called exceptions, because some errors are exceptional, otherwise they should be handled in the non-exceptional, standard flow of the program.
resoluteteeth 4y ago
> But why? Most modern languages try to get rid of exceptions (Go, Kotlin, Rust). All three of those languages actually have exceptions, they just don't encourage catching exceptions as a normal way of error handling Also, while the trend now seems to be for newer languages to encourage use of things like result types, one of the main reasons for that is that in current languages it is easier to show that functions can potentially failure in the type system using result types rather than exceptions. Otherwise, there isn't necessarily inherently a strong reason to prefer one or the other, and it's possible that future languages will go back to exceptions but have a way to express that in the type system using effects, etc.
mort96 4y ago
No clue if this is the reason, but exceptions are actually really fast. With them (or longjmp-based error handling), the "happy path" gets to not even thing about errors. With error returns (be it Go's error interface, Rust's Result type, or C's "this function returns a negative number on error" pattern), you need a branch after every call which might fail, which does have a measurable (if usually small) impact on performance. Given pigz's entire raison d'etre is performance, it wouldn't surprise me if this impacted the choice of error handling style.

Kotlin does have exceptions[1] [1] https://kotlinlang.org/docs/exceptions.html#java-interoperability https://kotlinlang.org/docs/exceptions.html#java-interoperab...

switchbak 4y ago
They said "try to get rid of", which to me is akin to de-emphasizing. Of course you'd have to deal with exceptions since you're running on the JVM and want to Interop with Java code, that doesn't mean it's idiomatic code.

jallmann 4y ago

Golang has panic / recover / defer which are functionally similar to exceptions. It's actually a fun exercise to implement a pseudo-syntax for try/catch/finally in terms of those primitives.

makapuf 4y ago
Go has exceptions but its definitely not advised to use those as an error mechanism. Recover is really a last chance effort for recovery, not a standard error catching method.
- brigandish 4y ago
  That's why they're called exceptions, because some errors are exceptional, otherwise they should be handled in the non-exceptional, standard flow of the program.

resoluteteeth 4y ago

> But why? Most modern languages try to get rid of exceptions (Go, Kotlin, Rust). All three of those languages actually have exceptions, they just don't encourage catching exceptions as a normal way of error handling Also, while the trend now seems to be for newer languages to encourage use of things like result types, one of the main reasons for that is that in current languages it is easier to show that functions can potentially failure in the type system using result types rather than exceptions. Otherwise, there isn't necessarily inherently a strong reason to prefer one or the other, and it's possible that future languages will go back to exceptions but have a way to express that in the type system using effects, etc.

mort96 4y ago

No clue if this is the reason, but exceptions are actually really fast. With them (or longjmp-based error handling), the "happy path" gets to not even thing about errors. With error returns (be it Go's error interface, Rust's Result type, or C's "this function returns a negative number on error" pattern), you need a branch after every call which might fail, which does have a measurable (if usually small) impact on performance. Given pigz's entire raison d'etre is performance, it wouldn't surprise me if this impacted the choice of error handling style.