pdf-devel
[Top][All Lists]
Advanced

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

Re: [pdf-devel] I'm Back at last


From: Hardy Falk
Subject: Re: [pdf-devel] I'm Back at last
Date: Thu, 13 Dec 2007 21:17:39 +0100
User-agent: KMail/1.9.5

Am Donnerstag, 13. Dezember 2007 00:06 schrieb address@hidden:

> 3. For pdf_error I'm considering writing wrappers for those
> functions available on lib/error.c and to write new ones for
> gnupdf as needed. OTOH, I'm pretty new on the project to know
> which error types should be added. I guess we should analyse
> each module on each layer and decide from there, don't you ?

Some observations from pdf_function.c:
Error reporting from a leaf module tends to be cryptic for a 
mere user. For example, a pdf function dictionary may miss a 
required key, the dictionary data may be inconsistent in 
various ways, a type 4 function definition may have a syntax 
error in its sublangage, and so on. 

There are errors at function call time,too.
A PDF shading function may be called millions of times,
reporting each error is probably not useful.
I'd need some way to defer error reporting.
What about a pdf dictionary as "error object" ?
It might be passed freely, accreting context as it moves?
 
>   /* memory module errors */
>     PDF_EOUTOFMEM
Internal error reporting is quite different: we might need to 
take some action. pdf_create_function() is quite complex, and 
it is hard enough to avoid memory leaks in the presence of 
errors. IMHO, it doesn't pay to have more than one error path 
in the code flow, e.g. zero indicates success, any other value 
is some error.

BTW,  my copyright assignment is finished. I hope I'll find time 
to write useful test functions real soon now.
Best wishes.


















reply via email to

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