EditComponentValue()

[Centripidity]

But my question was about compile-time rather than run-time checking.

I'm not sure about JAVA in general but it certainly won't let you create a short MIDI message outside of a catch/try block so perhaps it's up to the class developer to decide on the compile behaviour.

[ColinP]

perhaps it's up to the class developer to decide on the compile behaviour.

I'm wondering how this works exactly.

I've looked at the javac options...

https://docs.oracle.com/javase/7/docs/t ... javac.html

...and there doesn't appear to be anything obvious there, so I'm figuring this must be language level.

On the runtime options I've quickly scanned through the -switches and there's nothing that leaps out about what is different between VMD debug mode, VMD normal mode and VM proper mode. But there's a fair amount of detail in there so no doubt I've missed something.

https://docs.oracle.com/javase/8/docs/t ... /java.html

[honki-bobo]

The behavior of a JAVA program in case of an exception depends on at least two things:

1) Is it a checked or an unchecked exception?
An unchecked exception is a java.lang.RuntimeException or java.lang.Error and all of their respective subclasses, like NullPointerException, IndexOutOfBoundsException or NumberFormatException. The compiler does not require that you catch or specify runtime exceptions (although you can).
You can find more information in the JAVA documentation.
An InvalidMidiDataException inherits from java.lang.Exception and is not a descendant of java.lang.RuntimeException and is therefore a checked exception that needs to be handled.

2) Is the exception handled further up the call stack?
I don't have any information about how VM handles exceptions outside of a module, but I would suppose that exceptions are handled in some form on a higher level to prevent the JVM from crashing.

So if you want to avoid NumberFormatExceptions popping up in your logs you will need to ensure that newText can actually be parsed to a double in EditComponentValue before passing it on to the call to super.EditComponentValue.

Hope this helps.

Best regards,
Martin

[ColinP]

Thanks Martin, that explains the unchecked/checked thing. I figured there must be a relatively straightforward answer!

But on the EditComponentValue format execption thing you can't fix it by passing a valid newText string to super.EditComponentValue().

I just tested this by passing "1" to the superclass via newText.

Code: Select all

@Override
public void EditComponentValue( VoltageComponent component, double newValue, String newText )
{
   // add your own code here

   newText = "1";

   super.EditComponentValue( component, newValue, newText );
}

If you run this in debug mode in VMD it works as expected if the string is a valid double but throws an exception otherwise.

Therefore the exception must be being thrown BEFORE a module's EditComponentValue() is called not after.

[ColinP]

This whole thing is a bit strange really as although one reason for using EditComponentValue() is to enable us to do some math to say change the range or law of a number it also works if you pass arbitary text like a note name providing you aren't running in debug mode. And that is presumably the intention else why pass the string as a parameter?

Also it doesn't make sense for the superclass method to parse newText as what would reparsing the string do if you've already parsed it and changed newValue?

Yet you have to call the superclass method to pass the newValue.

I just did another test and if you pass garbage to the superclass method via newText it doesn't throw an exception so the newText parameter is simply being ignored in the superclass method.

My conclusion is that the whole thing works something like this...

Code: Select all

void editValue( String userString )
{
	component.SetValue( component.EditComponentValue( Double.parseDouble( userString ), userString ) );
}

With the format exception from ParseDouble() being logged but not thrown when not in debugging mode.

Edited to say, I know EditComponentValue() doesn't return anything but it was more elegant to express the idea this way.

[honki-bobo]

That's a very interesting find!

Correct me if I'm wrong here, but that would mean that the NumberFormatException must be occurring in the implementation of the VoltageKnob or VoltageComponent class and there is basically nothing a developer can do about it.

What's also curious is that in the stack trace of the NumberFormatException the highest (or lowest depending on your view) entry is voltage.core.Values.ParseStringToDouble and not VoltageKnob or the module class.

[ColinP]

Yup, basically it's an untrappable problem exhibited by every VM module that until Centripidity found it hadn't been noticed because it doesn't have any serious fallout outside debugging mode beyond causing a log entry.

[UrbanCyborg]

Just out of curiosity, is there some kind of unmentioned requirement that newValue has to be equivalent to the newText string? That might account for one of the exceptions Colin saw in his testing.

Reid

[honki-bobo]

@Reid: Doesn't seem like it. I did a quick test by adding a single knob to an otherwise empty module and changed the newText like so:

Code: Select all

public void EditComponentValue( VoltageComponent component, double newValue, String newText )
{
	// add your own code here
	newText = "" + (newValue + 0.1);
	super.EditComponentValue( component, newValue, newText );
}

This didn't cause any issues (except the already discovered NumberFormatException when entering values that cannot be parsed to a double).

[Aarnville]

This has been bugging me this week. I can't find any way to prevent the exception but I have observed that the exception does not happen as long as there is something that can be parsed as a number at the start of the string.

So "123.4" and "123.4 banana" both parse into 123.4 without an exception but "banana" throws the exception.
Like others in this thread I expected to be able to manipulate the newText var after I have parsed it to prevent the exception.

My use case is that I want the user to be able to enter a number and a unit for the value so, for example, they can choose to enter any of "567 mV", "567mV", "0.567 V" , "0.567V"and get the same result. I've successfully implemented that but I'm still vulnerable to the case where the user makes a typo and it doesn't look like we can do anything at our end of the food chain. Outside of the VMD environment there don't seem to be any ill effects and the user is unaware of the exception but it still makes me squirm a little.

@CherryAudio. It would be nice if we could have more control over this stuff. I quite often use a knob to select between text values (e.g. Note names). It's easy to make the tooltips look right but user entry is a different matter at present. An excellent extension would be to add support for a pop-up menu for user edits on knobs and switches and the ability for us to declare what sort of input the control takes and to have a means to process that type of input. But at the simpler end of things maybe look at how newText is treated because it doesn't look like it's working as intended at present.