[pbs-devel] [PATCH proxmox] schema: removed excessive newlines in error messages

[Thomas Lamprecht]

nit: s/removed/remove/, commit message should describe what they
change in the commit itself, so they make most sense if written in
the imperative.

Am 01/09/2023 um 10:12 schrieb Gabriel Goller:
> The output does not look good on console/task view when there is an
> empty line after the first error and trailing newlines after
> the last error. Removed the newlines.

I mean, as there are explicitly two newlines in a literal before
you patch it seems like somebody though it looks better that way
;-)

But sure, being more concise and providing less output, while keeping
a good readability, has definitively its merits!

The double occurrence of "error" is also something we could try to
avoid.


> Signed-off-by: Gabriel Goller <g.goller at proxmox.com>
> ---
>  proxmox-schema/src/schema.rs | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/proxmox-schema/src/schema.rs b/proxmox-schema/src/schema.rs
> index f087706..596adee 100644
> --- a/proxmox-schema/src/schema.rs
> +++ b/proxmox-schema/src/schema.rs
> @@ -101,14 +101,14 @@ impl fmt::Display for ParameterError {
>          let mut msg = String::new();
>  
>          if !self.is_empty() {
> -            msg.push_str("parameter verification errors\n\n");
> +            msg.push_str("parameter verification errors\n");

This is debatable, maybe we could do the following:

1. If there's exactly one parameter error collapse it to a single line, e.g.:

```
Error: parameter verification failed - 'file-name': value does not match the regex pattern
```

Or even more condensed:

```
Error: parameter 'file-name' - value does not match the regex pattern
```

2. if there are more than one error use a line by error but also use
bulletin point to keep a higher readability, e.g.:


```
Error: parameter verification failed:
- 'file-name': value does not match the regex pattern
- 'some-number': value is not in range X to Y
- 'foo-bar': value is to common
```

The only thing, from top of my head, speaking against doing 1. at all would
be that it's making parsing a bit harder, but tbh., we never guaranteed
error message stability, and if one depends on such stuff they should use
the API – so not seeing that as a blocker.

What do you think?

>          }
>  
>          for (name, err) in self.error_list.iter() {
>              let _ = writeln!(msg, "parameter '{}': {}", name, err);
>          }
>  
> -        write!(f, "{}", msg)
> +        write!(f, "{}", msg.trim())

this I'm fine with doing unconditionally.

>      }
>  }
>