Refactor usage of 'err()' with miniaudio results

[vittorioromeo]

Refactors the commonly used

err() << "...message..." << ma_result_description(result) << std::endl;

pattern into

MiniaudioUtils::printErr(result, "...message...");

This is not only nice to avoid some repetition and gain conciseness, but I am planning to make future changes to the err API that, after this PR, would only need to be applied once for all miniaudio error reporting code.

[eXpl0it3r]

Maybe we can discuss what API changes you're thinking of first.

On its own, I find this less readable, as I have to go and look up what printErr does exactly, plus it potentially removes some flexibility, in case you wanted to stream-out more information. This seems to outweigh the repeated ma_result_description call for me.

[vittorioromeo]

Maybe we can discuss what API changes you're thinking of first.

First step would be to hide sf::err in a priv namespace. Users should not stream to sf::err directly, it is an implementation error stream of our library.

With that, an explicit sf::redirectErrStream function would be added as part of the public API, allowing users to redirect the output of sf::priv::err without actually having to enter the priv namespace.

I also want to explore a format-based API in the future for err, obviating the whole arcane guard-based approach of #3010.

All of these changes would end up affecting every single usage of err.

[binary1248]

Technically, miniaudio returns ma_result values. If we want to cut down the verbosity of printing them then maybe it would be simpler to just provide an operator<<(ostream&, ma_result) until we have a newer way of reporting errors?

[coveralls]

Pull Request Test Coverage Report for Build 9103444480

Details

• 0 of 34 (0.0%) changed or added relevant lines in 5 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage remained the same at 51.729%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/SFML/Audio/MiniaudioUtils.cpp	0	5	0.0%
src/SFML/Audio/Sound.cpp	0	5	0.0%
src/SFML/Audio/SoundStream.cpp	0	5	0.0%
src/SFML/Audio/AudioDevice.cpp	0	9	0.0%
src/SFML/Audio/SoundRecorder.cpp	0	10	0.0%

Files with Coverage Reduction	New Missed Lines	%
include/SFML/Audio/SoundRecorder.hpp	1	0.0%

Totals
Change from base Build 9089388041:	0.0%
Covered Lines:	10477
Relevant Lines:	19034

---

💛 - Coveralls

[vittorioromeo]

Technically, miniaudio returns ma_result values. If we want to cut down the verbosity of printing them then maybe it would be simpler to just provide an operator<<(ostream&, ma_result) until we have a newer way of reporting errors?

That would couple us even further to a stream-based API and would not help to make it easier to make changes to err without affecting the entire codebase, I don't think it's the right way forward.

[binary1248]

I don't think it is a strong argument that this change makes changing err() significantly less work-intensive. err() usage in audio is just a fraction of the total usage throughout the library. Considering that this kind of an overhaul should not really occur that often (hopefully not again for at least 10 years), optimizing err() usage in a single module to save a bit of time for such a rare occurrence doesn't pay off for me, especially since as @eXpl0it3r mentioned you won't be able to determine exactly what is printed by just looking at the site where the error is produced.

I would just bite the bullet, make the err() changes, adjust all the necessary bits of code however many they might be and call it a day for the next 10 years.

[vittorioromeo]

I don't think it is a strong argument that this change makes changing err() significantly less work-intensive. err() usage in audio is just a fraction of the total usage throughout the library. Considering that this kind of an overhaul should not really occur that often (hopefully not again for at least 10 years), optimizing err() usage in a single module to save a bit of time for such a rare occurrence doesn't pay off for me, especially since as @eXpl0it3r mentioned you won't be able to determine exactly what is printed by just looking at the site where the error is produced.

I would just bite the bullet, make the err() changes, adjust all the necessary bits of code however many they might be and call it a day for the next 10 years.

I only see that as an added benefit, in my opinion the PR has value regardless of that as a general DRY refactor.

[ChrisThrasher]

I'd rather we solidify our final error logging API before making changes like this. I summarized all my thoughts on the matter in this comment.

[vittorioromeo]

Not worth arguing over this one.