It seems like that bug would be safeguarded here (https://chromium.googlesource.com/chromiumos/platform2/+/master/biod/fpc_biometrics_manager.cc#531), but I agree we need to return an error instead. 

As for the specific error code, I don't want to conflict with any error code that acquire_image_ generates, which is documented here (https://chromium.googlesource.com/chromiumos/platform2/+/master/biod/fpc/fp_sensor.h#87).

According to fp_sensor.h, error have negative code, but it didn't specify which negative code are used, so maybe return 4 for the bug identified? 

It might, yes, but I'm not sure how AddImage would behave with an empty image. It might crash or register something strange. So yes, let's fix it :-)

Don't use return code 4, we may later need that value for a more valuable return code of fp_sensor_acquire_image(), say for example a made up FP_SENSOR_TOO_SLOW.

I'd return -ENOMEM because it seems the most likely cause of error in that case. It's OK if we can't make the difference with fp_sensor_acquire_image() returning -ENOMEM, since it's the same root cause anyway. Ideally, we could do 2 things:
- add more logs in error cases to easily tell which of the calls failed (assuming at that point you can still log, not sure that's the case if we're really running out of memory...)
- also bubble up the error codes in calls to libfp inside CreateImage() and return those