Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

do we want error handling to be mostly user-side or code-side? #43

Closed
wchristian opened this issue Feb 21, 2017 · 2 comments
Closed

do we want error handling to be mostly user-side or code-side? #43

wchristian opened this issue Feb 21, 2017 · 2 comments

Comments

@wchristian
Copy link
Collaborator

I got thinking about this looking at your most recent commit, containing this:

    RETVAL = glewInit();
    if ( !RETVAL )
        _done_glewInit++;
OUTPUT:
    RETVAL

It would be nicer for the user if that would do the following instead:

croak( "Error %d while initializing glut.", RETVAL );

However while pondering about this, i thought it might be good to decide on one facet of handling and try to do that one as much as possible.

What are your thoughts on this?

@devel-chm
Copy link
Collaborator

devel-chm commented Feb 21, 2017

This seems to duplicate issue #36 which was left open because I think the user should not have to know internal details of GLEW to have OpenGL::Modern do the right thing. That part has not been completed. In general, we should support "raw" error handling a la C OpenGL API and with additional perl-ish error handing with better error messages where possible assuming no significant performance penalty.

@wchristian
Copy link
Collaborator Author

This question is a superset of the one posed in #36, i guess.

I read your response as "in general i prefer to have things die rather than return error"?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants