Summary
The current ProblemReport implementation is fully dynamic and represents an each problem report entry as a collection of strings effectively.
So when each report entry is raised and added into the ProblemReport bucket, its practically impossible in any reliable way what error was happened and correlate it with exactly that report which was raised in the particular place.
For example considering the following code
...
if is_valid_1 {
report.invalid_value(
"ver",
&ver.to_string(),
"ver < now + future_threshold",
&format!("Document 'ver' timestamp {ver} cannot be too far in future (threshold: {future_threshold:?}) from now: {now}"),
);
}
...
if is_valid_2 {
report.invalid_value(
"ver",
&ver.to_string(),
"ver > now - past_threshold",
&format!("Document 'ver' timestamp {ver} cannot be too far behind (threshold: {past_threshold:?}) from now: {now:?}",),
);
}
...
From the Rust perspective you cannot distinguish what was failing exactly afterwards, or the only way what you could do is the following
report.entries().contain("cannot be too far behind");
Which is totally unreliable and hard to maintain.
The idea is move to more typed approach by submitting not just a String report messages, but instead some typed object.
Summary
The current
ProblemReportimplementation is fully dynamic and represents an each problem report entry as a collection of strings effectively.So when each report entry is raised and added into the
ProblemReportbucket, its practically impossible in any reliable way what error was happened and correlate it with exactly that report which was raised in the particular place.For example considering the following code
From the Rust perspective you cannot distinguish what was failing exactly afterwards, or the only way what you could do is the following
Which is totally unreliable and hard to maintain.
The idea is move to more typed approach by submitting not just a
Stringreport messages, but instead some typed object.