[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error reporting should be improved

From: Peter Rosin
Subject: Re: Error reporting should be improved
Date: Tue, 29 Dec 2009 23:23:56 +0100
User-agent: Thunderbird (Windows/20090812)

Den 2009-12-29 23:09 skrev Bob Friesenhahn:
On Tue, 29 Dec 2009, Peter Rosin wrote:

This is because the last error was overridden by the subsequent tries. Maybe we should stop trying once the right file was found. This way the right message could be given to user.

The trouble is that it is not dlopen that gives this message, it is
dlerror that gives the message, and it would be terrible to use
string comparison to dig out the cause of the failure. And that's
just for the dlopen loader, who knows how the other loaders behave
on obscure systems in wierd corner cases. Finding a reliable way
to catch all errors that are not "file not found" or equivalent
and quit early will not be an easy task.

The loaders typically just report CANNOT_OPEN when something fails,
and the ltdl core has no reliable way of knowing the underlying

Errors from the preopen loader can be overwritten, but the first error reported subsequent to the preopen loader should be retained. It seems like what we need is a flag that indicates if the error is allowed to be overwritten. The alternative is error message concantenation, but that might lead to ugly results.

I'm just saying that it is not going to be easy to deduce if an
error is allowed to be overwritten.

Have a look at libltdl/loaders/dlopen.c:vm_open(). It basically
calls dlopen and sets the error to CANNOT_OPEN if dlopen fails.
The ways I see to dig out the underlying failure is to either call
dlerror and parse the string (Eeek!) or replicate the dlopen
internals and arrive at the same cause as dlopen did (EEEK!).

Not fun at all.


They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]