Might be nice to always call `exporter.finish_exporting`

Description

When an exception happens inside Exporter (for whatever reason) - itemcount never gets increased (that’s OK). But then during closing, the code doesn’t get chance to act

This is the place in the code:

https://github.com/scrapy/scrapy/blob/master/scrapy/extensions/feedexport.py#L357

Perhaps the lines 357 and 353 should have been swapped?

Additional context

I’m using slot.storage to open a database; and an exporter to start a session – store() gets called (to close connection to the database) but session didn’t have chance to commit – yes, there is nothing to commit, but still - given the semantics (also visible from the code – when file is supposed to be a file descriptor it might be worth consideration to always call finish_exporting to give the file descriptor chance to react before it is closed by the parent object)

necessary caveat: I might be mis-using the API and it is a minor detail, so please forgive if this looks silly (and feature not a bug)

[wRAR]

If you mean a test case for making sure it’s ohly called when start_exporting() was called it would just be a test spider with some exporter enabled and some different edge cases like zero items, maybe an exception happening at some early point etc.

[wRAR]

Even if slot.finish_exporting() was called without the start being called, it wouldn’t do anything because it checks for the flag/boolean set by start. Hence even if it gets called , it wont do any harm. Am I right?

Yes, this sounds correct.

if test will be required can you point me to an already written test case, which I can use as an example.

I don’t have one handy, but it looks like tests/test_exporters.py is a place with a lot of tests of the related code.