-
Notifications
You must be signed in to change notification settings - Fork 361
fn type_name_of_val<T> is non-deterministic #243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
As for me enforcing the error shape is quite limiting in AWS api (as well as e.g. the shape of messages (enforcing JSON, XML instead of using raw bytes (hello protobuf), sorry for offtopic...). We might try not hardcoding // user code
#[derive(Debug)]
struct FooError {
foo: i32,
}
todo_impl_display!(FooError); // imagine std::fmt::Display impl here
impl Error for FooError {}
#[derive(Debug)]
enum EnumedError {
A, B,
}
todo_impl_display!(EnumedError);
impl Error for EnumedError {}
// Nope: This will confict with the blanket impl
// impl lambda_runtime::HanderError for EnumedError {
// fn type_name(&self) -> &'static str {
// match self {
// EnumedError::A => "A",
// EnumedError::B => "B"
// }
// }
// }
fn main() {
let err = lambda();
println!("type_name: {}", (*err).type_name());
}
fn lambda() -> Box<dyn lambda_runtime::HanderError> {
if 2 + 2 == 4 {
Box::new(FooError { foo: 42 })
} else {
Box::new(EnumedError::A)
}
}
// lambda_runtime/lib.rs
use std::error::Error;
trait HandlerError: Error + Send + Sync {
fn type_name(&self) -> &'static str {
std::any::type_name::<Self>()
}
}
impl<T> HandlerError for T where T: Error + Send + Sync {} The problem with this implementation is that even thou we can provide the automatic type name of the error we cannot guarantee its semver stability, because as from
And we cannot allow the user to override So at the end of the day, the blocker for nice implementation is the |
Hmm, an idea has just come to my head suddenly. use lambda_runtime::HandlerError;
#[derive(HandlerError)]
#[error_type = "USER_ERROR"] // this bit is optional (uses std::any::type_name::<T>() or literally struct Identifier by default?)
struct UserError {
why_i_failed: String
} |
We used to that in the previous iteration of this runtime, lots of folks complained. This current As for your previous, insightful, comment, those are all good points. I've tried to address portions of your comment in #241 (comment), but I recognize that I didn't fully address it. |
Yup, I use what is currently at crates.io but there is no proc macro derive for /// ErrorType generated by it is
/// std::any::type_name() of the underlying error
/// No semver guarantees, use it only for diagnostics
struct DiagnosticError {
err: Box<dyn Error + Send + Sync>,
kind: &'static str,
}
impl<T> From<T> for DiagnosticError
where
T: Error + Send + Sync
{
fn from(err: T) -> DiagnosticError {
DiagnosticError {
err: Box::new(err),
kind: std::any::type_name::<T>()
}
}
}
impl HandlerErrror for DiagnosticError {
fn error_type(&self) -> String { // we might use fmt::Formatter here instead
self.kind.to_owned()
}
} This way users will have this utility DiagnosticError for general simple cases, but they might use proc macro derive or implement HandlerErrror manually if they rally need to |
👋 hey folks this issue has been stale for two years. I've decided to close it because the runtime has changed significantly enough and this is not a significant issue. If you feel strongly about keeping it open let me know, happy to discuss further. |
|
It seems that function fn type_name_of_val in lib.rs always returns the same value:
which is propagated to the response and CloudWatch.
That value is not user-friendly and is hard to parse downstream.
Other parts of the code return values like InvalidEventDataError, which is friendly and consistent with what other runtimes do.
Proposal
Making later changes to this part of the code will break compatibility for the handler code, client applications processing the lambda response and monitoring applications parsing CloudWatch message. I would prefer us to make an interim change to minimize that impact.
If there is no consensus on this, we may just advise the developers to ignore this field for now and rely on the structured data inside
Diagnostic.error_message
.The text was updated successfully, but these errors were encountered: