Handle null values for collections in samples

[srnagar]

No description provided.

[github-actions]

No changes needing a change description found.

[weidongxu-microsoft]

I see, for autorest, origin code is passable, it logs error but continue with the empty List/Map.

In typespec, emitter converted the error log to error in diagnostic, and then compiler reports the error.

Let us see how it works in mgmt (many JSON example is not accurate, legacy problem). If there is too many other kind of type error on it, we may lower it to "log warning" than exception.

[srnagar]

It would be better to fix the samples or disable sample generation than to log warnings and ignore as that would result in bad samples getting generated.

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension

[XiaofeiCao]

I see, for autorest, origin code is passable, it logs error but continue with the empty List/Map.

In typespec, emitter converted the error log to error in diagnostic, and then compiler reports the error.

Let us see how it works in mgmt (many JSON example is not accurate, legacy problem). If there is too many other kind of type error on it, we may lower it to "log warning" than exception.

I'm not against it. Just for my understanding, will this be a case that "error log affects the emitter result"? Should we consider error logs failure for codegen?

[weidongxu-microsoft]

I'm not against it. Just for my understanding, will this be a case that "error log affects the emitter result"? Should we consider error logs failure for codegen?

There is code in emitter.ts to report warn/error from logging to diagnostic.
https://github.com/microsoft/typespec/blob/main/packages/http-client-java/emitter/src/emitter.ts#L170-L179

We log error in autorest, to say "this is error in JSON exmaple", but ignore that since it only affect test/sample. I think it is still reasonable.
(if we want failure, we'd throw like Srikanta did here)

With the code in emitter.ts, we seems had to use log.warn in this particular case, to avoid fail on test/sample value (even if they are invalid...).

[weidongxu-microsoft]

It would be better to fix the samples or disable sample generation than to log warnings and ignore as that would result in bad samples getting generated.

Yeah, that is the preference. Just mgmt had too many libs, and fixing them require contact service owner (we don't have a good list for contact).
And disable the whole sample/test may not be desirable, if only a few of them have problem.