LOCK * TO accepts uninitialized vars.

[a1270]

While looking into killrot i passed kill without double quotes.

lock steering to kill.

When you so ksp vomits out kos exceptions. WHEN THEN also accepts them:

when nope then print "yes".

Doing that in immediate mode will print "Unrecognized term: 'nope'" until the end of time. Locking steering to kill just ends the program and when then only spits out unrecognized term once when loading from file.

EDIT; This is what comes from lock.

kOSException: Exception of type 'kOS.kOSException' was thrown.
  at kOS.Expression.GetValueOfTerm (kOS.Term term) [0x00000] in <filename unknown>:0 
  at kOS.Expression.GetValue () [0x00000] in <filename unknown>:0 
  at kOS.BindingFlightControls+LockableControl.OnFlyByWire (.FlightCtrlState& c) [0x00000] in <filename unknown>:0 
  at kOS.BindingFlightControls.OnFlyByWire (.FlightCtrlState c) [0x00000] in <filename unknown>:0 
  at (wrapper delegate-invoke) FlightInputCallback:invoke_void__this___FlightCtrlState (FlightCtrlState)
  at Vessel.FeedInputFeed () [0x00000] in <filename unknown>:0 
  at FlightInputHandler.FixedUpdate () [0x00000] in <filename unknown>:0 

(Filename:  Line: 4294967295)

[a1270]

The WHEN... THEN issue seems to be the result of GetValueOfTerm never being able to return null. Not something i will attempt to fix after not being able to sleep.

[Dunbaratu]

Actually, in general this is a small piece of a wider effect, which is that "lock" statements never report their runtime errors because the computer doesn't try executing them until later in the background, and in that context it doesn't try to report errors to the user. So it's not just uninitialized variable errors that don't get caught. It's any other runtime problem executing the expression too. When the lock expression fails to execute, the user never sees a message why. I've had problems where I never could figure out what was wrong with my code until I changed a LOCK into a SET inside a loop instead and only then did KOS start reporting the runtime error in the expression to me.

So maybe the generic fix to this is to fix the fact that when evaluating a LOCK expression, the user doesn't see the errors reported. LOCK expressions are evaluated on the fly only at the moments they are used. So if on line 5 you write "LOCK var TO x+2." and then don't try to use 'var' until line 10, then during lines 6,7,8, and 9 the LOCK expression has never even been run yet. This is fine and makes sense to me and is a lot more efficient than running it again and again every line. The problem is that on line 10 when it finally does execute, the context in which it executes is one that doesn't report errors. If it did report errors, then at line 10 you'd get the complaint about the uninitialized variable, the first time you make use of the lock expression. And I think that would be fine as a fix.