> After so many years of trying, with three > We didn’t have a better solution at that time and didn’t pursue syntax changes for error handling for several yea

> After so many years of trying, with three > We didn’t have a better solution at that time and didn’t pursue syntax changes for error handling for several years. 3 is small, and it seems like there were more years of not trying at all. And the example of one proposal is telling. It had a major control flow issue, so got rejected, but then there is a recent proposal fixing those issues, and the post just goes on without further elaboration? > Unfortunately, as with the other error handling ideas, this new proposal was also quickly overrun with comments and many suggestions for minor tweaks, often based on individual preferences. How is this unfortunate? If the tweaks are good, update the proposal using them, so that's very fortunate? If they aren't, explain why there rejected? Or do you only expect a binary yes/no on the proposal as originally published? I mean, no wonder with such an approach the only way forward is to give up.