Re: [Freeglut-developer] add fgError() exit callback/routine

[Chris M. <ch...@al...>]

All-

I took another look at the issues around
the setjmp/longjmp and user defined error
handler for non-fatal error handling for
FreeGLUT.

First, I reviewed all the places where
fgError was called in the FreeGLUT 2.6
sources, here are the number of occurances
by the keyword searched (each corresponds
to a call of fgError):

134 FREEGLUT_EXIT_IF_NOT_INITIALISED
   3 FREEGLUT_INTERNAL_ERROR_EXIT_IF_NOT_INITIALISED
  18 FREEGLUT_EXIT_IF_NO_WINDOW
  13 FREEGLUT_INTERNAL_ERROR_EXIT
  28 fgError

The result of this analysis was that the
vast majority of the fgError (i.e. exit-based
error handling) usage was for user code
problems that are fatal in FreeGLUT:
forgetting to call glutInit() or calling
glutInit() more than once.  The rest were
more of the internal error type of a resource
that was needed and not available.

All were reasonable candidates for a user
defined error handler:  in the case of a
perl language binding, a call to the perlapi
croak() routine to allow the user program
within the perl interpreter to detect and
handle the error condition as required.

After that analysis, I realized that the
simplest implementation protecting the
existing GLUT API standard would be the
addition of two new init functions:

   glutInitErrorFunc()
   glutInitWarningFunc()

and the addition of the corresponding
defaults in the fgState structure.  With
the addition of these two routines and the
modification of fgError() and fgWarning()
to call the user defined handler if set,
we have a clear, simple method to extend
the FreeGLUT error handling to support
more embedded applications such as the
perl language binding.

The fact that the two functions are in
the glutInit* family of routines even
allows for the fact that they need be
called *before* glutInit() itself.

Thoughts?
Chris


On 7/11/2010 10:55 AM, Chris Marshall wrote:
> I updated the Feature Request with this idea:
>
>> I though of a better/cleaner way to handle this issue
>> without breaking the GLUT API. I realized that this
>> change in error handling would need to be handled
>> *before* the glutInit() call in order to work for
>> glutInit too.
>>
>> The idea is to add a command line flag to change
>> the behavior of glutInit on errors to not exit but
>> instead return immediately with an error message in the
>> argc/argv. If the glutInit completes successfully, a
>> standard-ish glutSetOption could be used to control the
>> error handling from that point on.
>>
>> A bit of a kludge for the first part but it doesn't
>> break existing glutInit usage except for the possible
>> change to the argc/argv values but this would only
>> happen if the -softinit (or whatever the option is
>> called) were passed to the glutInit call.
>
> The main user visible difference to FreeGLUT would
> be that glutInit would handle failure differently
> if it was passed the -softinit argument.  In that
> case it would return with the error returned as an
> amendment to the argv value.
>
> That would allow for non-fatal embedding of glutInit
> in other applications.  Once glutInit has succeeded,
> the remainder of the fix would be adding the ability
> to set an alternate fgError mode (maybe a routine to
> call before the exit).
>
> I think this approach "answers the mail" and keeps
> any grave turning over to a minimum.... :-)
>
> Cheers,
> Chris
>
> P.S.  Is there a way to search archives of the list?
> I have not found any easy way to review back discussions.
>
>
> On 7/9/2010 10:22 AM, Fay, John F Dr CTR USAF AFMC AAC/XRS wrote:
>> There was a discussion of "setjmp" and "longjmp" but it wasn't resolved.
>> I thought I heard Edsger Dijkstra turning over in his grave and I don't
>> know that we wanted to disturb his ghost further.  Has that changed?
>>
>> 	- John
>>
>>
>> -----Original Message-----
>> From: Chris Marshall [mailto:ch...@al...]
>> Sent: Thursday, July 08, 2010 5:33 PM
>> To: FreeGLUT developers list
>> Subject: [Freeglut-developer] add fgError() exit callback/routine
>>
>> This is regarding to an entry on the Feature Request
>> tracker at sf.net:
>>
>>      2116152 add fgError() exit callback/routine
>>
>> I just got bit by this one again.  The problem is
>> that fgError always exit(1) from FreeGLUT kills the
>> perl interpreter in the binding.
>>
>> The thought was to have some way to add a user
>> specified exit routine to be called instead for
>> fgError.  For our perl bindings, that could be
>> die which can be caught and processed for an
>> exception handler.
>>
>> In the meantime, I'm working around the problem by
>> duplicating the glutInit code so that I can catch
>> the exceptions myself before passing control to
>> the glutInit() routine.  That way the inputs should
>> be good and glutInit won't kill perl if something
>> goes wrong.
>>
>> This would be a problem for most any embedded
>> freeglut mode of operation.  I can submit a code
>> proposal....or am I missing some obvious way to
>> fix this problem in a portable way?
>>
>> Thanks in advance,
>> Chris Marshall
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Freeglut-developer mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freeglut-developer
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.830 / Virus Database: 271.1.1/2996 - Release Date: 07/11/10 02:36:00
>