Re: [Xen-devel] [PATCH for-next] CODING_STYLE: Document how to handle unexpected conditions

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Feb 28, 2019 at 06:49:05PM +0000, George Dunlap wrote:
> It's not always clear what the best way is to handle unexpected
> conditions: whether with ASSERT(), BUG_ON(), or some other method.
> All methods have a risk of introducing security vulnerabilities and
> unnecessary instabilities to production systems.
> 
> Document when to try to return an error for unexpected conditions,
> when to use BUG_ON(), and when to use ASSERT().
> 
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
> ---
> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> CC: Jan Beulich <jbeulich@xxxxxxxx>
> CC: Tim Deegan <tim@xxxxxxx>
> CC: Konrad Wilk <konrad.wilk@xxxxxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Julien Grall <julien.grall@xxxxxxx>
> ---
>  CODING_STYLE | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 79 insertions(+)
> 
> diff --git a/CODING_STYLE b/CODING_STYLE
> index 6cc5b774cf..51159970c0 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@ -120,3 +120,82 @@ the end of files.  It should be:
>   * indent-tabs-mode: nil
>   * End:
>   */
> +
> +Handling unexpected conditions
> +------------------------------
> +
> +GUIDELINES:
> +
> +Passing errors up the stack should be used when the caller is already
> +expecting to handle errors, and the state when the error was
> +discovered isn’t broken, or too hard to fix.

If the error is too hard to fix, what should the caller do after getting
an error? Should Xen continue with such broken state?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel