Allow not calling finish() when using the writers

[jmcarcell]

Forgetting finish() is likely a mistake and by the time the writer is destroyed what the user probably wanted to is to write. The RNTuple ROOT writer works like that and writes when the object is destroyed. For the RNTuple writer in podio this is already done.

BEGINRELEASENOTES

• Allow not calling finish() when using the writers

ENDRELEASENOTES

[tmadlener]

Very nice, and the right thing to do, IMHO. The only potential issue I see is anything that throws in the destructor will cause the program to terminate, so we would maybe have to try-catch in there?

Taking this a bit further: Do we ever need the functionality to "finish early"? I.e. long before a writer is destructed? If not we could just introduce a private function that does what finish does now, call that in the destructor and make the current finish a no-op and deprecate it.

[jmcarcell]

Very nice, and the right thing to do, IMHO. The only potential issue I see is anything that throws in the destructor will cause the program to terminate, so we would maybe have to try-catch in there?
But that is the same behavior we have right now, right? Probably no one was wrapping the finish() inside a try-catch. I can add one

Taking this a bit further: Do we ever need the functionality to "finish early"? I.e. long before a writer is destructed? If not we could just introduce a private function that does what finish does now, call that in the destructor and make the current finish a no-op and deprecate it.

This I don't know, if someone wants it. I guess you hold everything in memory until you write so there could be a case where it's better to write earlier. I don't think having the flexibility hurts but surely most people will stop using finish() if not's necessary so deprecating it also wouldn't be bad.

[hegner]

I do not think we need an explicit finish here any more. What we could keep in mind is an explicit option to flush buffers to disk so that things can be written out.
I however do not see yet a reasonable request for it.