Re: PostgreSQL's approach to assertion usage: seeking best practices
От | Aleksander Alekseev |
---|---|
Тема | Re: PostgreSQL's approach to assertion usage: seeking best practices |
Дата | |
Msg-id | CAJ7c6TMGHZNjjcQjikXSriC-mwhmJ_FmJvTts9az8HR9-tVXMw@mail.gmail.com обсуждение исходный текст |
Ответ на | PostgreSQL's approach to assertion usage: seeking best practices (Alexander Kuznetsov <kuznetsovam@altlinux.org>) |
Список | pgsql-hackers |
Hi Alexander, > As part of this effort, we conducted static analysis using Svace, which raised some questions regarding the use of theAssert() function. > We were unable to find clear answers in the documentation or previous discussions and would greatly appreciate your insights, > as these will influence how we approach future patch submissions: > > 1. General purpose of Assert() function: > - Is the primary purpose of the Assert() function to: > - Inform developers of the assumptions made in the code, > - Facilitate testing of new builds with assertions enabled, > - Accelerate development by temporarily placing assertions where defensive code may later be required, > - Or does it serve some other purpose? > > 2. Assertions and defensive code: > [...] > > 3. Approach to fixing flaws: > [...] Assert() describes an invariant - e.g. x should never be NULL here. It's present only in the debug builds. It has two purposes. 1. Check the invariants during the execution of the tests and usage of a debug build. 2. Serve as a description of the invariant for the developers. Adding Asserts() is usually a good idea unless the invariant is too expensive to check and/or complicated to read/understand. -- Best regards, Aleksander Alekseev
В списке pgsql-hackers по дате отправления: