Cherry Audio Forums

That's normal. A knob value must be a numeric string value. Every other sign than numbers, e and '.' or ',' is not valid.
If you want be able to input letter groups, you need to use an editableLabel.

Hi Roland,

The point is that we want our modules to be able to cope with "user error". If someone types garbage in to the Edit Value field we want to handle it gracefully and code throwing an uncaught exception isn't good.

Although the format exception doesn't cause any serious problems, technically this is a bug.

Rats. Now you've all got me paranoid about what I may have overlooked.

Reid

Whenever you think there aren't any bugs lurking you've lost touch with reality....

Oh, I lost touch with that years ago. Happens when you work on a game company schedule.

Reid

Yeah, working 25 hours or more a day does have that effect.

seal58 wrote: ↑Mon Feb 06, 2023 6:17 pm That's normal. A knob value must be a numeric string value. Every other sign than numbers, e and '.' or ',' is not valid.
If you want be able to input letter groups, you need to use an editableLabel.

I can understand why you would assume that, particularly if you have been using VMD for a long time, I don't think this is true, at least not anymore. By overriding GetTooltipText() a knob can be made to display a non-numeric value. When you go to edit the knob the value displayed is the non-numeric value so the user would expect to enter such a value. In fact, they wouldn't know what the underlying numeric value was.

Also, since the 2.7 Programmers' Guide was written, EditComponentValue() has gained a new argument which contains the actual text entered by the user. I imagine this was done so that module code could process this text and turn it into the equivalent numeric value.

Either way, Colin's point is nonetheless valid. If the user makes an invalid entry, Voltage should not be throwing an exception that can't be trapped by a module's own code.

I've contacted CA and this has now been logged as a bug.

A question to those of you more familiar with Java than me.

Shouldn't the throws keyword force the compiler to report an error if a call to a method that can throw an exception either isn't inside a try...catch block or the enclosing method doesn't also use the throws keyword?

I think I've seen this happen before when coding MIDI so why does this compile time check sometimes apply and sometimes not?

I guess it would be arduous to fully comply to this as exceptions could pop up inside much of the lower level but I'm curious about the exact mechanism.

I'm a Java novice at best but it seems not to be the case in VMD at least. Perhaps Voltage is suppressing them to prevent users from having the program crash. I have had a number of bugs that I found difficult to track down until I ran them in the debugger and found all sorts of errors (like index out of bounds) that aren't reported in a release build and don't stop the program from continuing to run.

I'm very new to VMD but whenever I have a bug, or even if I think everything is running ok, I run on the debugger to make sure there isn't something going wrong that isn't otherwise reported.

Yeah, I found out the hard way that important things like boundary violations don't flag up when not in debugging mode. It makes testing difficult as some scenarios can't be simulated in VMD.

Note out-of-bounds access might not cause exceptions but can still crash the code or otherwise cause untold havoc. So outside debugging mode it feels like going back to the bad old days of pointers in C/C++.

I don't think javac has any options for switching off exception handling so my guess is that the runtime differences are down to HotSpot virtual machine switches. I'm slowly learning more about these things but it's time-consuming doing such research so I'm still in the dark about a hell of a lot of things.

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