5

I have a struct, and I have a new method that I have written, that generates the object and return its pointer.

Now I also have another method for example, Close, but as of now, it is not mandatory to call this method once the object is created. I want to make sure that this method has to be called if the object is created. How do I do that in Golang? If this is possible, I don't know what is this termed as either. Please help. Thank you.

scott
  • 1,557
  • 3
  • 15
  • 31

2 Answers2

10

There is no way to force the call of a Close() method. The best you can do is document it clearly that if the value of your type is not needed anymore, its Close() method must be called.

In the extreme situation when a program is terminated forcibly, you can't have any guarantees that any code will run.

Note that there is a runtime.SetFinalizer() function which allows you register a function which will be called when the garbage collector finds a value / block unreachable. But know that there is no guarantee that your registered function will be run before the program exits. Quoting from its doc:

There is no guarantee that finalizers will run before a program exits, so typically they are useful only for releasing non-memory resources associated with an object during a long-running program.

You may choose to make your type unexported, and provide an exported constructor function like NewMyType() in which you can properly initialize your struct / type. You can't force others to call its Close() method when they are done with your value, but at least you can stop worrying about improper initialization.

icza
  • 389,944
  • 63
  • 907
  • 827
  • Thank you. Not just destructors, but if there is a method like `object.run()`, which sets some variables, and without which the object can throw some nilpointer error, is there any way to mandate the user to use `.run()` method? – scott Apr 24 '16 at 17:19
  • Perfect @icza, Thanks a lot. – scott Apr 24 '16 at 17:25
  • Can I ask why this part of the original answer was deleted?: *"...Also return an interface type and not a concrete type, and the interface should contain everything others want to do with your value. And your concrete type must implement that interface of course."* Was it deleted because returning a concrete type is better than returning an interface? If that's the case, why is it? – starriet Feb 28 '22 at 12:00
  • @starriet Implementing interfaces in Go is implicit (there is no declaration of intent). Interfaces should be created when and where needed. All existing types will implement that interface if the method set is a superset of the interface. – icza Feb 28 '22 at 12:19
  • @icza Thank you. So, if I make a constructor function like `NewMyType()`, it is recommended to return a concrete struct, not an interface of that struct? (I thought returning an interface of the struct was the recommended way in the original answer.) – starriet Feb 28 '22 at 14:00
  • 1
    @starriet It's better to return concrete types, and leave creating / using interfaces where it's needed. – icza Feb 28 '22 at 14:08
  • Thank you for your clarification. I think that's more close to the "duck typing" style, which is kind of Go style in my opinion. – starriet Feb 28 '22 at 15:11
2

In short, it is not possible in go.

The term you are looking for is destructors, which Go does not implement. For more information, read through the excellent answer here: Go destructors?

Community
  • 1
  • 1
Andreas Schyman
  • 181
  • 4