Improvements Needed on Exception Handling

[KrLite]

The serde pack in 3.8.0 is really convenient to use, however the current exception handling method is too strict.

Imagine the scenes below:

1. I don't want to write @SerdeDefaults for all of my fields, but I can provide a default config instance every time a deserialization happens, and I want to fallback all the missing values to the provided config instance. It is intuitive but isn't supported by Night Config. Currently encountering a value whose config entry is missing or whatever, Night Config only checks for a SerdeDefault annotation, then throws a SerdeException if not found. There isn't an option to choose an instance for falling back, and a single missing entry will cause the entire config file deserialization process to fail hardly. Although it can be handled by programs that call the deserialize method, the process cannot be restored, and there's no way to get the fields that are no problem with deserializing.
2. When handling with enums or so, I want my program to be more tolerant. For example, if the config value of an enum references to a non-existing enum constant, I want to just ignore it and fallback to the default one specified in SerdeDefault. It is also intuitive but isn't supported by Night Config. Because this tolerance can only happen in the specified bottom-layer value deserializer, so it may be tricky to implement such a thing. But this can really allow a single typo to ruin everything, and I believe there's a better way to handle the exceptions and continue the normal deserialization progress.

Please improve the exception handling methods to at least cover the 2 scenes mentioned above. They are really crucial problems in production environments.

Something more: as the documents not updated, I'm curious that is there any ways to restrict a specific config entry's display type? For example, restrict an integer to display in HEX or OCT or BIN in toml, or to restrict a table to display inline like config = { k1 = "v1", k2 = "v2" } instead of a large normal table in toml. If this feature is supported or will be supported in the future, please let me know.

[TheElectronWill]

Hello, Thank you for your detailed suggestions. There could be more tolerance, I'll see how it's possible to implement that.

Regarding the "display" settings:

• you can use TomlWriter.setWriteTableInlinePredicate to define a custom rule to choose whether tables should be written inline or not
• there is currently no way to write numbers in a different base, but this is planned for a future major version of the library