Re:JEP draft: Exception handling in switch
by mrkeen on Friday April 19, 2024 @04:38PM
(#40091650)
I'm with you right up until the dedicated syntax point.
Failure modes aren't going away, (especially with our tendency towards slinging JSON at each other as fast as possible.)
So, make a good syntax for it! Then accounting for failure becomes pleasurable, so developers will do it. Take the hit and make your user base learn it once, early.
But perhaps I misunderstood what 'dedicated syntax' is. I want syntax for map/flatMap because it's really broadly useful. But I don't like it when one particular implementation gets special syntax, and the rest don't (looking at you, Rust-Result, and null-coalescing operators).
> Exceptions are a failed experiment
They still need to exist in some form. We're not going to case-match over every plus and divide to deal with overflow and div0.
"Exceptions should only be used exceptionally" is wisdom that never really stood a chance, because mainstream languages didn't provide a way to handle non-exceptional errors.
Failure modes aren't going away, (especially with our tendency towards slinging JSON at each other as fast as possible.)
So, make a good syntax for it! Then accounting for failure becomes pleasurable, so developers will do it. Take the hit and make your user base learn it once, early.
But perhaps I misunderstood what 'dedicated syntax' is. I want syntax for map/flatMap because it's really broadly useful. But I don't like it when one particular implementation gets special syntax, and the rest don't (looking at you, Rust-Result, and null-coalescing operators).
> Exceptions are a failed experiment They still need to exist in some form. We're not going to case-match over every plus and divide to deal with overflow and div0.
"Exceptions should only be used exceptionally" is wisdom that never really stood a chance, because mainstream languages didn't provide a way to handle non-exceptional errors.