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 in the future we
will instead actually invoke a PTA that talks to journald.
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. They actually have very important data. 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]
