Skip to content

Add section on error reporting to coding guidelines#48

Open
kinkie wants to merge 1 commit into
mainfrom
coding-guidelines-error-reporting
Open

Add section on error reporting to coding guidelines#48
kinkie wants to merge 1 commit into
mainfrom
coding-guidelines-error-reporting

Conversation

@kinkie

@kinkie kinkie commented Jun 21, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@kinkie kinkie changed the base branch from update-coding-guidelines to main June 21, 2026 20:50
@rousskov rousskov self-requested a review June 22, 2026 00:29

To report an error and abort the current transaction, throw a `TextException("descriptive text", Here())`.
Use `Assure(condition)` to test an invariant and abort the current transaction.
To check system-leve invariants, where a failure needs to terminate Squid, use `xassert(condition)`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To check system-leve invariants, where a failure needs to terminate Squid, use `xassert(condition)`
To check system-level invariants, where a failure needs to terminate Squid, use `xassert(condition)`

@yadij

yadij commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

There is also static_assert for compile-time invariant. Alex has some very specific requirements about wording the descriptions there.

It would be useful to mention what "report" means: where, how, and what does it look like for each of these cases?

Also, IIRC Alex had a definition of "invariant" that did not quite line up with C/C++ standard definition of the terminology. I came away from the Must() vs Assure() discussion thinking there was a disjoint paradigm in play.

@rousskov rousskov left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I welcome this attempt at documenting error handling and invariant checking guidelines. Related code is often problematic, and documentation can help reduce the number of problems and correction overheads.

There is at least one bug and several problematic statements in the current version. It is also very difficult to derive the correct decision making algorithm from the proposed sentences. As Amos has noted, it is probably best to cover static_assert cases here as well.

I will find the time to rewrite this. I do not recommend making changes until then.

@kinkie

kinkie commented Jun 23, 2026

Copy link
Copy Markdown
Contributor Author

I welcome this attempt at documenting error handling and invariant checking guidelines. Related code is often problematic, and documentation can help reduce the number of problems and correction overheads.

It's more than this. Coding Guidelines can (and should) feed LLMs, both code-writing and code-reviewing ones.

There is at least one bug and several problematic statements in the current version. It is also very difficult to derive the correct decision making algorithm from the proposed sentences. As Amos has noted, it is probably best to cover static_assert cases here as well.

I will find the time to rewrite this. I do not recommend making changes until then.

Feel free to improve

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants