Debug/trace logging?

[quarnster]

Would you be against adding in support for different levels of logging/tracing?

The most recent example of information I'd like to know would be to warn if the #llgo name attribute won't take the name for some reason. Being silent isn't good and neither are panicing or erroring out. But a regular printf isn't good either if there are a lot of messages written with unknown source.

I've used for example log4go in the past.

[axw]

Hmm. I haven't seen a compelling need for it yet, but in theory I'm not. I'd rather stick with the gc approach of no warnings, error all the time. It could be useful to add different levels of logging for debugging, though.

In the case of #llgo name specifically, I don't see why you wouldn't want to error out, though. Seems like something that should fail quite loudly. What're your thoughts on that?

[quarnster]

I'm just wary of the use of panics as the current bailout method when something goes wrong. In my mind panic should mean that something in llgo is broken and an issue should be opened up here, not that the input the user gave llgo is broken and the user needs to fix their own code. I mention panic as in the example of attributes there's no error return. Maybe there should just be a func bailout(error) that prints the error and exits as an alternative.

I'll use a panic in this example for now and a better way can be considered as part of #4.

[axw]

I absolutely agree that panics are less than ideal, though I think error conditions should be fairly rare given that everything comes in type-checked. Panics as a control flow mechanism should be used sparingly, but it may be with merit here, as in go/types.