Different exit codes for different failure types about instaloader HOT 4 OPEN

Yes, this would be a nice feature.

I was wondering whether there was some kind of standard or convention for how exit codes are assigned in typical unix applications, but it seems there is none except of zero being a success status and non-zero an error status. Apart of that, all tools seem to follow their arbitrary mapping of error types to exit codes.

Instaloader already distinguishes many types of errors with different exception types, it would be great to map those into return codes for the cli application. We could somehow resemble the exception tree, combined with some semantical/logical grouping of error types into the error code, e.g. by assigning a few bits to the group and the other bits to a finer granulation, as this might simplify the parsing of the exit status. So we would both have a fine granularity without making the feature less useful I think.

I could imagine something like

So this would imply a grouping of

This is close to the grouping given by the exception tree, which itself was built on the way of how they must be handled internally.

However, this is only a suggestion after brief consideration. I do not want to rule out the possibility that there might be a more sensible or appropriate mapping.

from instaloader.

I think too many exit codes would actually add too much complexity for little benefit. If the user needs that much detail, they can use instaloader as a module and catch the actual exceptions.

[Moreover, retrofitting the exit codes in the existing code is not trivial - and the more different codes there are, the more work is necessary.]

But in addition to the general categories I had identified, some of the ones you listed can be useful:

• Too many requests - I'd say this one deserves its own error code. However, from what I remember, if a 429 is received, the program just waits and then retries, indefinitely. It does not abort the program, unless --abort-on is used.
• Login required - Probably useful
• Profile does not exists / is private - Could be useful. Would be more a warning than an error, since just one of many profiles could have failed. On the on other hand, some users occasionally make their profile private (or disable them) temporarily, and I'm not sure I need to mark a instaloader run as 'failed' just because of that.

Basically your idea of groups is quite similar to my proposal, but I'm not really convinced that the level of detail provided by the lower byte is really useful. And from what I remember, some errors you listed ("bad request", "forbidden", etc) don't cause the program to terminate, just to retry or skip that item.

from instaloader.