Question

I have a number of functions that parse data from files, usually returning a list of results.

If I encounter a dodgy line in the file, I want to soldier on and process the valid lines, and return them. But I also want to report the error to the calling function. The reason I want to report it is so that the calling function can notify the user that the file needs looking at. I don’t want to start doing GUI things in the parse function, as that seems to be a big violation of separation of concerns. The parse function does not have access to the console I’m writing error messages to anyway.

This leaves me wanting to return the successful data, but also raise an exception because of the error, which clearly I can’t do.

Consider this code:

try:
    parseResult = parse(myFile)
except MyErrorClass, e:
    HandleErrorsSomehow(str(e))

def parse(file): #file is a list of lines from an actual file
    err = False
    result = []

    for lines in file:
        processedLine = Process(line)
        if not processedLine:
            err = True
        else
            result.append(processedLine)
    return result
    if err:
        raise MyErrorClass("Something went wrong")

Obviously the last three lines make no sense, but I can’t figure out a nice way to do this. I guess I could do return (err, result), and call it like

parseErr, parseResult = parse(file)
if parseErr:
    HandleErrorsSomehow()

But returning error codes seems un-pythonic enough, let alone returning tuples of error codes and actual result values.

The fact that I feel like I want to do something so strange in an application that shouldn’t really be terribly complicated, is making me think I’m probably doing something wrong. Is there a better solution to this problem? Or is there some way that I can use finally to return a value and raise an exception at the same time?

Answer 1

Nobody says the only valid way to treat an “error” is to throw an exception.

In your design the caller wants two pieces of information: (1) the valid data, (2) whether an error occurred (and probably something about what went wrong where, so it can format a useful error message). That is a completely valid and above-ground case for returning a pair of values.

An alternative design would be to pass a mutable collection down to the function as a parameter and let it fill any error messages it wants to emit into that. That will often simplify the plumbing in the caller, especially if there are several layers of calls between the parser and the code that knows how to do something with the error messages afterwards.