Re: [Libcdio-help] Custom read_audio function

[Bastiaan Timmer]

Thanks for the quick reply!

--- On Tue, 11/22/11, Rocky Bernstein <address@hidden> wrote:

paranoia_read() is from Monty/Xiph's paranoia;  thus it follows that API, which as you have noted is not to return NULL on error.  I don't see why it couldn't  do so, but that would be changing the paranoia API. So it would be best to get it changed both in paranoia as well as libcdio's use of it.

Right, that would seem like a good idea, but it is a long-term solution (especially considering the slow changes to Xiph's paranoia). Also, not returning NULL is only part of the problem (see below).

The way paranoia expects a program to handle errors is via that callback. You note that you did get an error through the callback. The part that is tricky here is that with all this indirection, I'm not sure how the callback can actually get the error parameter. But we could make sure there is some way.

Well I'm not completely sure having the error parameter in the callback would help that much, because the callback can't make read_paranoia() return, right? As I said, the problem is not so much that paranoia_read() does not return NULL (which would help me decide to break out of the reading-loop), the big problem is is that paranoia_read() doesn't return at all! And as far as I can tell there nothing I can do (returning something, setting some variable) in functions accessible to me (the callback and the read function) that will force paranoia_read to return.

As for the multiple level of error messages, well that is all under your control. The low-level libcdio error messages can be turned off by setting the log level.  And then there is the std::cout you added. And finally there is the error message in the callback. Choose however many or which you want to see.

Yes, I knew all that, my program accepts a verbosity option which I had cranked up to get this output (plus the added std::cout). The logging options in libcdio are nice and much appreciated.

As for the question of at what point you should bread from the read loop on an error depends on you. Probably if you get a BAD_PARAMETER_OP, that's probably not going to change so you could bail immediately. Other errors may require more discrimination. The whole idea of cd-paranoia though is to tolerate errors on the hope that some of them are transient. But with that flexibility comes the responsibility of the program to make the determination.

So, the only solution I have thought of until now, is to have read_audio(), when it fails, not _return_ the error code but _throw_ it. Then I can just catch it right outside of the read_paranoia() loop, and inform the user of the problem. But indeed, I'm wondering if I should throw on all possible errors. Looking at the list in device.h, I guess the program might as well exit on DRIVER_OP_BAD_PARAMETER, BAD_POINTER, UNSUPPORTED and NOT_PERMITTED. I suppose I could fix the problems indicated by UNINT and NO_DRIVER (after breaking the loop of course). I am not sure about DRIVER_OP_ERROR and MMC_SENSE_DATA because I really don't know what they mean. Any thoughts?

Also, please let me know if you have any other solution than throwing, I have actually managed to never write throwing functions up til now, so now I think I have to read up on C++ exception handling. Also, C programmers in my situation wouldn't have this luxury.

By the way, when I made the typo in the mmc_read command that resulted in this issue, the typo had the effect of passing a NULL pointer as 2nd parameter ('Place to store data.'). Shouldn't it have returned DRIVER_OP_BAD_POINTER instead of BAD_PARAMETER?

Thanks again!
Bas Timmer