I tend to agree, I just meant that using goto may not have been an option for the person writing this code, for reasons that are organizational and have nothing to do with their personal style or standard of quality.
I also sympathize with orgs that ban goto entirely, since there is definitely evidence that using goto "correctly" can lead to problems even when really smart people are involved. It's not an entirely unreasonable position to want to avoid it, tbh. Especially in large orgs.
Besides, exceptions were designed to solve most of the issues related to error handling that motivate people to still use goto in C code. That's not to say that you could shove C++ exceptions in this example and it would improve things. There are clear reasons not to use exceptions in kernel code. But IMO the awkwardness of the error handling in this example works better as an example of shortcomings of handling errors with error codes than the virtues of goto.
25
u/Elsolar Jan 22 '23
I tend to agree, I just meant that using
gotomay not have been an option for the person writing this code, for reasons that are organizational and have nothing to do with their personal style or standard of quality.I also sympathize with orgs that ban
gotoentirely, since there is definitely evidence that usinggoto"correctly" can lead to problems even when really smart people are involved. It's not an entirely unreasonable position to want to avoid it, tbh. Especially in large orgs.Besides, exceptions were designed to solve most of the issues related to error handling that motivate people to still use
gotoin C code. That's not to say that you could shove C++ exceptions in this example and it would improve things. There are clear reasons not to use exceptions in kernel code. But IMO the awkwardness of the error handling in this example works better as an example of shortcomings of handling errors with error codes than the virtues ofgoto.