TheButlah commented on code in PR #278:
URL:
https://github.com/apache/teaclave-trustzone-sdk/pull/278#discussion_r2789491237
##########
optee-utee/src/parameter.rs:
##########
@@ -185,3 +306,101 @@ impl From<u32> for ParamType {
}
}
}
+
+#[derive(Debug)]
+pub struct BiggerThanCapacityErr {
+ requested_size: usize,
+ capacity: usize,
+}
+
+impl Display for BiggerThanCapacityErr {
+ fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
+ write!(
+ f,
+ "requested size {} but this is bigger than the capacity {}",
+ self.requested_size, self.capacity,
+ )
+ }
+}
+
+impl CoreError for BiggerThanCapacityErr {}
+
+impl From<BiggerThanCapacityErr> for crate::Error {
+ fn from(_value: BiggerThanCapacityErr) -> Self {
+ crate::Error::new(ErrorKind::Overflow)
+ }
+}
Review Comment:
> Seems these new error types are only used for printing error messages
before being converted into a standard optee Error?
I provide the `From` conversion to make the example code more terse, but I
believe there is value in more clearly communicating what the nature of the
error is (along with a richer error message). In production code for example,
we actually wrap all of our errors with `anyhow` and then right before we
return to optee, we log that more comprehensive error out, and having the
ability to clearly see in logs the chain of errors and their descriptions
(without having to clutter every call site with tons of if lets and printlns),
is very valuable.
There are other reasons too. For example, in the system we use at work, our
serial is not accessible therefore if we want to see what errors happened, we
need to return the error to the CA. So we can't rely on `trace_*!()` macros. If
we used only `ErrorKind` we would have *very* little information necessary to
debug the system, since so little information can be encoded. Instead, it makes
sense to have richer error types that can be returned to the CA, and we get to
defer the printing of those errors instead of serializing them via `format!()`
or `trace_println!()` Additionally, trace_println!() is extremely slow and
becomes a performance bottleneck very fast.
The way this PR does it is the best of both worlds: it provides the
conversion for those that just want a `?` and tersely writing code, but it
retains the structured error for those that need/want it.
Side note: some of these error types are more than just richer error
messages. The error returned when converting access for example, contains the
original type (since the function takes `self`) so that if the conversion
fails, the caller doesn't drop data and can try again with a different access
type.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
