[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] [Libcdio-help] Custom read_audio function
From: |
Bastiaan Timmer |
Subject: |
Re: [Libcdio-devel] [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:
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