I am not really convinced that new best practices will be developed or in included in the standard library because andrew thinks that there isn't an issue.
replyI have a partially written blog post in my head, as I've spent a lot of time thinking about the problem. I'd have preferred if there was a change to the reader/writer interfaces, but even without it, I'm starting to see patterns that work and can be applied to any code to make it safe. People just need to be aware of the problem and that's my goal, although I'm probably failing if my tone is creating the drama, so I'm learning how to communicate it better.
replyI don't think you are creating any drama to be honest. I understand how frustrating it must be.
replyThere is a similar issue in kotlin where a cancellation is marked via a CancellationException but that extends IllegalStateException and thus Exception. Because of that it gets caught and swallowed all the time. This is a constant source of bugs for me at work and google has resorted to a bunch of linting to get around this design mistake.
The most frustrating part about it for me it's Andrew's argument: just write correct code. I have C at home.
replydeleted
replyIn the future, tooling can run those checks statically on IR.
replyUnfortunately, it you want to handle errors right, it's overly verbose, so no one really does it. That's my problem really. Even in the blog post snippet, I could have show well behaved code, because I'm well aware of it, but then the error handling would be more code than the part I'm trying to showcase. Static analysis will not help there.
replyIn the future, it would be good to not need to require that unwritten tooling
replyYeah, I feel Andrew's tooth brushing argument is quite weak here. It is basically the same as the defence of C's error handling, which Zig fixed.
replydeleted
reply