search

thedocruby / resounding

A New Minecraft mod that provides realistic audio physics using parallel wave tracing and an improved physics algorithm.
https://thedocruby.dev/resounding
GNU Lesser General Public License v3.0
84 stars 4 forks source link

(Old) ALUtils.java: Delay logged message 'building' #104

Closed acodili-jg closed 1 year ago

acodili-jg commented 1 year ago

Move to: #105

Original description > ### TLDR; > > This update introduces `checkError(Supplier)` for lazily built log messages. > >
> > #### The Issue: > > In the current code, messages passed to `checkError(String)` are, potentially complex and eagerly built, string. However, this approach may unnecessarily create messages that may never be used due to the way `checkError(Consumer)` works. > > #### The Proposed Solution: > > `checkError(Supplier)` tries to address the issue by providing a way to defer the message building when it's needed, saving unnecessary processing when no errors occur. > > #### Alternative Approach: > > As an alternative, the underlying logger's functionality can be used directly. One interpretation might discourage `checkError(String)` in favor of `checkError(Consumer)` to do the logging there, though it may result in duplicated code. > >
> > I would really welcome feedback and reviews as I don't understand why I'm so hesitant in making this pull request. (And thanks to ChatGPT for helping me make this more readable) > > #### Transparency > >
> > Original description. > > > > ### TLDR; > > > > `checkErrors(Supplier)`'s allow message strings, usually built before being sent to `checkErrors(String)`, to be made or built when needed lazily. > > > >
> > > > `checkErrors(Consumer` will only process or consume an error message if debug logging is enabled and when there is an error to work with. `checkErrors(String)` internally calls `checkErrors(Consumer)` with a consumer that consumes the parameter, the error message, as a message logged by the `Engine.LOGGER`. I propose an improvement to `checkErrors(String)`, or rather an alternative is the new method `checkError(Supplier) as we can provide it the how to build the message string we want, albeit if immutable data are used, and it will only perform the message building when a message is needed. > > > > Alternative: expose the logger part to allow the utilization of its functionality that otherwise was simplified as a single string. > >
ChatGPT's suggestion. > ### TLDR; > > This update introduces improvements to how errors are handled and logged in the `ALUtils` class. > >
> > #### The Issue: > > In the current code, error messages are logged using a fixed string format. However, this approach has some limitations, as it may log unnecessary messages or build complex error strings even when there are no errors. > > #### The Proposed Solution: > > To address these limitations, we are introducing a new and more flexible method called `checkError(Supplier)`. This method allows us to provide a "blueprint" for building the error message only when it's needed, saving unnecessary processing when no errors occur. > > #### What's Changed: > > 1. We added three overloaded `checkErrors` methods: > - `checkErrors(Consumer callback)`: This method takes a function that can consume the error message. It will only process and log the message if debug logging is enabled and when there's an actual error to report. > - `checkErrors(String message)`: This method calls the above method internally, but it now accepts a direct error message string. This is kept for backward compatibility. > - `checkErrors(Supplier messageSupplier)`: This method allows for lazy evaluation of the error message. It takes a supplier function that provides the error message when requested. > > 2. We also introduced new methods for handling specific types of errors, such as `errorApply`, `errorProperty`, and `errorSet`. These methods utilize the `checkErrors` functionality for consistent error handling. > > #### Why It Matters: > > By using the new `checkError(Supplier)` method and the improved error handling methods, we can build error messages more efficiently and avoid unnecessary overhead. Additionally, this enhancement gives developers more control over error logging and helps improve the overall code quality. > > #### Alternative Approach: > > As an alternative, we considered exposing the underlying logger's functionality directly, but we believe that the new `checkError` method provides a cleaner and more maintainable solution, keeping the logger implementation encapsulated. > > We welcome feedback and reviews to ensure that these changes are beneficial and align with the project's goals.

acodili-jg commented 1 year ago

Oh goodness, wrong branch. Forgive me, it's literally 10PM or \~22:00