What to do about identification via the Siegfried module that both has an error and identification results #266
Unanswered
ross-spencer
asked this question in
Q&A
Replies: 1 comment 1 reply
-
hey @ross-spencer this is interesting, perhaps this class of "errors" should go to the warning field instead? Errors should really be about reporting issues that prevent identification happening (e.g. permissions on the file, network failure) whereas warnings are there to suggest potential issues with files (empty, extension mismatch, etc.). This feels more like it belongs in that second category. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Given the skeleton file example below by way of illustration:
When identified via the Siegfried package, it will simultaneously return an error, but also an identification, mirroring the command line ID. However, when using Siegfried as a library the error returned usually takes on greater importance because it can often mean something more serious with the application.
Example code:
Packaged with file and go.mod/go.sum: example_sf_reader_main.zip
Example out:
I'm torn about how to treat it. There's useful info here, so maybe keep the useful info? Or throw it away given the error?
Or, should sf's handling be different here? there's an intellectual "error" but is it an actual "software" error?
Beta Was this translation helpful? Give feedback.
All reactions