> Because they know things will crash if they do They will crash or do whatever undefined behaviour either way.
>Thats a specious argument. Since most programmers fix crashing errors that >occur every time the program runs, the errors MUST depend on user input >otherwise they would be fixed if they occurred all the time. So unless you >apply analysis or exhaustive testing user input can always expose programming >errors, so if the program can politely decline to perform the user operation >and keep running its better than crashing. No, these assertions are meant only for programming error, using them for release-build control flow is not advised. See from the docs below: > The g_return family of macros (g_return_if_fail(), g_return_val_if_fail(), > g_return_if_reached(), g_return_val_if_reached()) should only be used for > programming errors, a typical use case is checking for invalid parameters at > the beginning of a public function. They should not be used if you just mean > "if (error) return", they should only be used if you mean "if (bug in > program) return". The program behavior is generally considered undefined > after one of these checks fails. They are not intended for normal control > flow, only to give a perhaps-helpful warning before giving up. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc5b10f03ea7f#commitcomment-23748190
