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 по дате отправления: