JUCE development futures

General JUCE discussion
1

I’ve got three bits of feedback I’d like to get as directions for JUCE 8.

Aside from the regular feature/performance improvements I’d love it it you looked at:

  • Error handling: improving result codes from functions
  • No unnecessary deprecations
  • Debugging features

Error handling

This is the big one.

When an error occurs please pass as much information as possible back to the caller. I’ll give two examples. We have an app that scans folders for MP3s. In the MP3 decode there is an assert:

        {
            jassertfalse; // This means the file is using "free format". Apparently very few decoders
                          // support this mode, and this one certainly doesn't handle it correctly!
            frameSize = 0;
            return ParseSuccessful::no;
        }

This then gets converted to -1 as a value returned from the MP3Decoder, and then even this already minimal error information is thrown away by AudioFormatReader::read as far as I can tell. To support a user who says their MP3 isn’t loading we’d have to get a copy of their MP3 and run the app inside a debugger.

The same is true of almost every network call. Network calls are even harder to debug as you can’t replicate the users environment. The operating system provides detailed and useful error information, e.g. Windows has GetLastError and you can tell whether you’ve got an SSL certificate problem, or a DNS problem. But JUCE just drops all this information, leaving us with just the ability to tell the user ‘Operation Failed’ with no further useful diagnostic information.

Please add a mechanism for getting extended error information and start using it everywhere. I’d settle for an out-of-band solution like GetLastError, it’d be ok.

Unnecessary deprecations

Can you stop deprecating old stuff that will never need to be updated. Sure, add MathConstants<double>::pi. but there’s no need to mark double_Pi as deprecated. That’s just making work for no reason.

Debugging features

Please add as many debugging tools as possible to JUCE.

I’ve got some examples in my juce toys repo, e.g. ComponentDebugger (which shows your component tree and helps answer questions about why components aren’t visible), a ValueTree browser, and scripts for Windows debuggers and LLDB to show information about JUCE objects.

It would be great to get higher quality versions of this stuff into the library, plus tools for helping debug repaint areas, repaint performance measurement, mouse clicks, keyboard stuff, focus issues and so on.

It’d save hours of peoples time if you could see instantly which components were getting events, why components weren’t visible.

It’d be even better if I could turn on loads of debugging information in JUCE debug builds without recompiling!

Cheers! Jim.

6 Likes
2

Absolutely. I’m sure the devs are already busy with plenty of ideas but here there are some more:

I think it would be extremely useful to have a standard way to generate Error Logs (of which Crash Dumps would be a subset). Ideally we would be able to switch them on and off if they had an impact on performance. I’d personally define different labels like processingThread, messageThread, etc so that those messages can be switched on and off depending on where they live (e.g. I’d disable by default the processingThread reports but I would always leave the messageThread reports which, in my case, would be more beneficial than the marginal increase in performance). The thread nature can be determined with a simple query but I think that custom labels would make it more flexible to adapt to particular circumstances.

As jimc says, every error should contain as much information as possible. It would be helpful that the error handler accepts a list of variables to be able to print their names and values like Array<pair<String,var> > maybe?

Finally the error handler should be able to be configured to optionally include asserts, write to the Error Log, include more or less info, etc. I often use #defines for the error handler because they allow me to adapt to the circumstances without any performance issues but I guess it would be more elegant (and cleaner) to use a custom constant lambda (if it is possible to do so without losing performance). Optional asserts combined with labels to be able to configure certain groups of errors would be very powerful in certain phases of the development where you want to check certain things that later on you don’t want to interrupt you with an assert (e.g. when you want to verify if a program responds well to rare conditions or format errors).

In other words, a well thought system that could be used across all JUCE classes and in our apps would speed up testing, enable users to easily report bugs and result in much more stable JUCE programs!

1 Like
3

I put in a feature request about improved component debugging, please upvote:

I also published a component inspector as a module — @jimc your component inspector was the inspiration, maybe it fits your needs, you can check out the features so far here (handling focus is planned).

The tool is definitely limited by JUCE not exposing things like paint timing (see Roland’s amazing work here that relies on a fork).

My feature request asks for more API abilities (like timing) as they would enable the community to build more cool things. However, if the JUCE team did want to add and maintain tooling like this, I’d offer myself as tribute be available for hire and would be happy to work on it.

2 Likes
4

Regarding error handling, in C++23 it has been added the std::expected class, which has exactly the purpose of making error reporting easier and more standardized across codebases without resorting to exceptions.

@timur does an excellent job at explaining it in this talk (link should take you at the correct 37:05 timestamp): How C++23 Changes the Way We Write Code - Timur Doumler - CppCon 2022 - YouTube