3 ms·
> At the same time, you don't want to be writing unit tests for every simple scenario. Yup, exactly. In a perfect world you would, but the world ain't perfect.
by randomdata 5y ago
> At the same time, you don't want to be writing unit tests for every simple scenario.
Yup, exactly. In a perfect world you would, but the world ain't perfect. Sooner or later you're accidentally deleting the wrong thing because you didn't test it/didn't test it correctly.
And for what reason? A language can guard against that kind of mistake quite well.
So, that still leaves us wondering why you don't find it advantageous for a programming language to be able to deal with these kinds of problems unless the problem is related to an error? If you have a solid foundation the problem with errors you are trying to show would disappear. Go only has problems with errors because it also has problems generally.
> Practicality matters, otherwise C is all we'd ever need, and we wouldn't be having constant CVE's etc.
Agreed. Which leaves it to be insane to only want to fix the problems with errors when everything wrong with errors is also wrong with every type. If you fix the error problem properly you've automatically fixed it for all types. Why on earth are you suggesting that you'd purposefully make the fix harder just to ensure that it only fixes errors?
> Rust errors compose nicely, and you're explicitly forced to handle them (unlike golang's), and are much harder to accidentally swallow or ignore compared to golang.
This isn't a feature of specialized error handling, but Rust's overall design towards helping with general state management. Rust alleviates the same problems for all types. Rust yet again shows us that errors aren't special and don't matter. Provide a good foundation for state management and managing error state becomes easy by virtue of just being yet another state. You are able to cleanly deal with errors in Rust because it took care to get the problem right generally, not because it took care to worry about errors at the expense of everything else.
Go could, like Rust, do more to help with general state management. It would be insanity to try and only do that for errors, though.
- azth 5y agoHow do you suggest golang handles stack traces then? It seems Rust has the same issue by the way: https://docs.rs/error-chain/latest/error_chain/ https://docs.rs/error-chain/latest/error_chain/ > If the RUST_BACKTRACE environment variable is set to anything but 0, the earliest non-foreign error to be generated creates a single backtrace If my understanding is correct, it means that you won't get stack traces for any external libraries or code that does not use this library. Because Exceptions in Java/C#/etc. are special, you will always have stack traces regardless of which code you're calling.