Re: [Libcdio-devel] [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