> Given the current troubles with the main library API and missing status > values, I'd say in the long run we'll be happier with a real status > return. OTOH, I don't much about go.
I'm not sure what the "current troubles" are (happy to hear more), but the way I've handled the nil case is in keeping with the way it's handled in the other function bindings for go. Adding an error return to all relevant functions seems like a big change that should be handled separately, yes? In defense of the current strategy, any caller can check for the nil case before calling. -T