|
From: | Bastiaan Timmer |
Subject: | Re: [Libcdio-help] Custom read_audio function |
Date: | Tue, 22 Nov 2011 07:20:59 -0800 (PST) |
Thanks for the quick reply! --- On Tue, 11/22/11, Rocky Bernstein <address@hidden> wrote:
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).
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.
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.
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |