In a production environment, panic! may not be a good choice.

[RickSKy]

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))

[XAMPPRocky]

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?

[RickSKy]

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.

[RickSKy]

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.

[Syndelis]

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.

[PPakalns]

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.