In a production environment, panic! may not be a good choice.
RickSKy opened this issue · comments
In a production environment, panic! may not be a good choice. Can we directly return the error message as a string, i.e., change the code from
panic!( "Failed to format a message for locale {} and id {}.\nErrors\n{:?}", lang, text_id, errors ) to
Some(format!("Failed to format a message for locale {} and id {}.\nErrors\n{:?}", lang, text_id, errors))
Thank you for your issue! I believe there are try_ variants for when you want to avoid panics, can you provide a specific example of where you're running into this?
I want to encapsulate the use of LOCALES.lookup_with_args in a Linux service. Sometimes, due to programming negligence, the name of the arguments may be written incorrectly, but this will not result in a compilation error. Instead, it will cause a runtime crash, which is not very user-friendly. Implementing compilation errors might be difficult, but directly printing error messages is a better approach as it allows for easy identification of the error, without the need to run the program multiple times to see the crash information.
The mentioned try_ function has left me a bit confused. Does the library provide such a function? Could you please provide an example? Thank you.
Even with try_ methods, it will still panic when no arguments are provided to messages expecting them (here). This method should definitely return a Result, instead.
Wanted to provide some feedback that this change is needed.
When hot reloading translations that has an invalid translation this panic is triggered even when calling try_ family method.
With #63 hot reloading even with invalid translations works nicely, i can handle error correctly. I am using this feature daily.