Community
Participate
Working Groups
I have the following private function declared in a library (targeted at JS): private function createAndShowDialog(title string in,message String in, content widget in, buttons DojoButton[] in) returns(DojoDialog) Note the message parameter is non-nullable. I then have the following code that invokes this function. Note "null" is being passed as the message parameter: return(createAndShowDialog(title, null, content, buttons)); This code compiles and generates, but fails at runtime with the following message: Uncaught exception occurred during handling of undefined.onClick event [CRRUI2005E] A null reference cannot be used. [CRRUI2094E] Here are the EGL function calls leading to this error: DojoButton.DojoButton.setAttribute() [native JavaScript] I think EGL should convert a null literal (possible null variable) passed into a non-nullable field (covert to the default value of the type, so in this example an empty string - ""). We perform other conversions (e.g. covert a literal 6 into a decimal 6 if passed into a function that expects a decimal). I don't think we necessarily "dirty up" our null story by doing this since the developer has made the conscious choice to declare the parameter as non-nullable, so they expect this parameter variable to not be null when accessed/used in the function.
I have prepared (but not committed) the changes to do this (setting of the default for the type) for both javaGen and javaScriptGen, however, I am not sure we want to allow this in the first place. Sure, it makes it so that a user can code the passing of a null, but if you try to do that with a regular assignment, you get a validation error. For example: s string; s = null; The above gives a validation error, so my feeling is that the passing of a null should also produce a validation error. We need to have Tim weigh in on this, I'll hold off committing the changes until we get a decision.
I do not think that we should implement this for the same reason that Jeff described in comment 1: s string; s = null; The language should be consistent, and the above sample does not result in s being assigned a value of "".
Marking as 'won't fix'. If you still think this should be changed, please re-open and discuss the issue with Tim.
Closing based on discussion.
