Because it's in my common module, I want to keep the possibility open that I might add in more statuses. Hence the failure check would have to be any negative number, not specific ones. This is why I went with regex. Ofc I note that my regex matches any number in the example, but in my real code, I address that.
And yes, the success string will never be just a number. At the very least even if "" is passed as the folder and -1 is passed as the number and it passes all checks, the sub would return "/-1" | [reply] |
Then what you have is pretty good. Assuming you've got a reliable branch based on error code (which you appear to), you could then use that as a dispatch so that the processing function itself had no knowledge of the errors themselves. Just go one step farther and take the error code (once you know that's what you've got) and pass it in to some error-handling function which either knows, or has access to a table of some kind that knows how to handle individual errors. That keeps your driver function sufficiently generic that it could handle anything as long as "errors are always negative numbers."
| [reply] |
This sort of “specialized knowledge” about the return-codes should be encapsulated within a sub within that package. If the caller wants to know, “is this an error?”, then it should be able to get the answer by calling a sub which answers that question, yes or no. Because, someday, that’s gonna change, and when it does, you do not want to be grepping through the source-folder, finding 100 occurrences of logic that must be changed, and changing (oops...) 99 of them.
Code defensively. If a call occurs in an “impossible” situation, check for that situation, and (Carp) confess the sin. The best – the only – agent that can detect such bugs is the computer itself. Nothing is more “inefficient” than a bug, and the time spent trying to find it.
| |