> 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.
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.
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.
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.
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.
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.
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.