Re: [Lcms-user] lcms 2.0 - error handling

[Hal V. E. <hv...@as...>]

Getting this back to LCMS 2.0.  Looking at the code there have been some 
significant changes in 2.0.  For example it still has cmsSetErrorHandler() but 
this is for backward compatibility and it now has support for creating an 
error handler plug-in that appears to have more functionality although it may 
not have fixed the underlying issues.

The version 1.x error handling code has a number of problems.  

1. The calling app can set the default behavior using cmsErrorAction() and one 
of the values is LCMS_ERROR_SHOW.  But setting it to LCMS_ERROR_SHOW has no 
affect on the code path and acts just like the default setting of 
LCMS_ERROR_ABORT.

2. Setting LCMS_ERROR_IGNORE will result in segmentation faults in some cases 
because the error is not handled.  Actually the existing error handling code 
never really handles the error all it does is aborts execution if there is an 
error. 

3. If a user defined error handler is setup and the user supplied error 
handler does not short circuit the call chain with something like a setjmp() 
then execution returns to the statement after the call to the error handler(s) 
and in many cases this will result in a segmentation fault in the LCMS code.  
So the only realistic option is for the user supplied error handlers to short 
circuit the call chain to prevent LCMS from continuing on and seg faulting..  
It is this situation that is the root problem that is causing application to 
use things like setjmp().  How can we tell LCMS to not abort and still not seg 
fault while returning to the place where the user application invoked LCMS?

Now looking at the error handling code in LCMS 2 it is all new code and even 
the cmsSignalError() function is completely different code.  But like the 
older code it's default behavior is the same if LCMS_ERROR_SHOW or 
LCMS_ERROR_ABORT are set as the default action by the user app.

In addition the new error handler plug-in functionality allows the calling 
application to set up three entry points for handling errors and warnings.  
One each to handle errors, warnings and a function that is called to handle 
exit conditions.  So this is more flexible but I am not sure how this can deal 
with situations where the user app wants to continue but doing so by letting 
LCMS continue will cause a seg fault or some other major error.  

I am not sure how to solve this issue but unless LCMS 2 will not seg fault 
when the user app sets LCMS_ERROR_IGNORE or it uses a user provided error 
handler that effectively does the same thing then we still have the same basic 
issue.  How can this be setup to return control to the statement after the 
call to LCMS that raised the error condition without LCMS seg faulting? 

For what it's worth I think the current LCMS way of doing this is, just 
barely, OK for command line line programs but it has major issues for those 
writing applications where aborting execution is NOT an option like in GUI 
apps (Scribus, LProf. Krita, Digikam, UFRAW, XSane...).  For those 
applications we need a way to trap errors so that they can be handled 
gracefully.  We can do this with setjmp() but this is very ugly and has many 
issues including that it is only available is some languages and is not well 
suited to multi-threaded applications. 

Hal