On Oct 25, 2011, at 7:50 PM, Daniel Morissette wrote: > On 11-10-25 11:20 AM, Howard Butler wrote: >> All, >> >> I have prepared an RFC to support the implementation of providing user >> context data in CPLErrorHandling scenarios. I suspect this is a >> non-controversial proposal with limited applicability and impact for most >> folks, and I hope to pass the RFC and implement the proposed code in trunk >> in a week or so. >> >> http://trac.osgeo.org/gdal/wiki/rfc37_cplerror_userdata >> > > Please forgive the naive question, but to make things really simple from the > API standpoint, instead of accessing the pUserData via > CPLGetErrorHandlerUserData(), could we not instead define a new type of error > handler that receives the user data as argument?
Yes, but the RFC also says "an approach that mimics and looks similar to the existing operations is likely the best approach for GDAL -- if not the cleanest approach in general." for this reason. I was trying hard to not upset our existing pile of apples. > > typedef void (CPL_STDCALL *CPLErrorHandlerEx)(CPLErr, int, const char*, void > *); > > I guess that would imply changing the CPLErrorHandlerNode to support two > types of handlers. Maybe that's why you didn't choose to take that approach? Adam Nowaki explored this option, and I put together a patch that implemented it on the ticket. As Even pointed out [1], this approach causes some complications with how CPLSetErrorHandlerEx vs CPLSetErrorHandler works and what it should return. In the end, it seemed to me as though this might be more trouble than it was worth. [1] http://trac.osgeo.org/gdal/ticket/4295#comment:6_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
