juce::Expression::Helpers::EvaluationError in v3.2.0-161


#1

I'm getting new exceptions thrown in latest version of JUCE.  Thing is, the exception class is private, so I cannot access the "description" field to log the exception message from within my application.

The problem is that "Helpers" is private in juce::Expression::Helpers, so Helpers::EvaluationError is unavailable:

modules/juce_core/maths/juce_Expression.h:249:12: error: ‘struct juce::Expression::Helpers’ is private

I think the exceptions are new in 3.2.0-161, or close to that version.  Exception is thrown from what I thought was a valid call:

    find_button.setBounds( "parent.width - 87, 6, left + 40, top + 40" );

In my case, using the debugger the exception thrown is Unknown symbol: "parent" from visitRelativeScope().  Guess I need to call add before I call setBounds.  :)

One possible fix which would really help is if the EvaluationError constructor was re-written like this:

EvaluationError( const String& desc) : std::exception(desc.toStdString()), description(desc) {...}

This way the std::exception base class would contain the error message when what() is called when applications catch std::exception.  The other solution would be to make the exception class public.


#2

Correction:  std::exception does not take a parm.  You'd have to make it inherit from something like std::runtime_error to have the ability to pass in a "what" parameter.


#3

Found some places where the fix for the new exception behaviour isn't trivial.  There are places when orders are first opened where I create many components, setup everything I need including calling setBounds( "...." ).

Problem is addAndmakeVisible() isn't called since the parent isn't known until later in the application once these components are needed and inserted into the proper place.

The problem is this no longer works with the new behaviour of throwing exceptions when "parent" (or other sibling names) are not yet defined.  Is there an easy way around this new exception behaviour?


#4

Thanks. Damn, it seems harder than expected to remove exceptions from the codebase, even though there are only about 3 places where we used them!

Will get onto this v. soon and sort it out..


#5

Had the same problem just now after updating JUCE.  Now I have to revert the update...


#6

Sorry - had forgotten about this one! I think I've fixed all the places where exceptions could escape now - let me know if you still have any problems..