Got a bug for the team. Don't ask me how long it took me to track it down. Consider this code and the effect of running it: ============== public class Foo { bad_pre_constructor(); fun float bad_pre_constructor() { <<< "bad_pre_constructor, this =", this >>>; } } Foo bad_foo; <<< bad_foo =", bad_foo>>> ============== % chuck foo.ck bad_pre_constructor, this = 0x634720 bad_foo = 0x0 ============== Note that the instance of bad_foo is null. Now consider this code: ============== public class Foo { good_pre_constructor(); fun void good_pre_constructor() { <<< "good_pre_constructor, this =", this >>>; } } Foo good_foo; <<< good_foo =", good_foo>>> ============== % chuck foo.ck good_pre_constructor, this = 0x634720 good_foo = 0x634720 ============== Note that the instance of good_foo is a reasonable non-null value. Did you spot the difference? "bad_pre_constructor" is declared (improperly) to return a float, but it doesn't, and an instantiation of Foo silently returns a null. "good_pre_constructor" is properly declared with a void return, and an instantiation of Foo returns a good value. So yes, this was operator error -- it's an error not to return a value when you claim you're going to. But ChucK fails silently, at least until you get hit with a NullPointerException some time later in the execution. This is not friendly behavior. - Rob P.S.: Uh, is this the right forum for reporting bugs like this?