Skip to content
This repository has been archived by the owner on Apr 10, 2024. It is now read-only.

DEV: C++ exceptions vs. error codes #57

Open
wesm opened this issue Oct 24, 2016 · 2 comments
Open

DEV: C++ exceptions vs. error codes #57

wesm opened this issue Oct 24, 2016 · 2 comments
Milestone

Comments

@wesm
Copy link
Owner

wesm commented Oct 24, 2016

On some contemplation, I am thinking it may lead to overall cleaner C++ code if we use exceptions for error reporting instead of status codes. These exceptions should be truly exceptional -- for example, it would be better to deal with argument validation and "can't fail" exceptions with DCHECK macros. User-visible argument validation can be handled in the Python wrapper layer.

@llllllllll
Copy link

These exceptions should be truly exceptional

Should error returns still be used in the case of unexceptional failures, like lookup out of bounds? At least with gcc, exceptions are very slow so we don't want to dispatch through them often. Another option is to have checked and unchecked functions like std::vector::at vs std::vector::operator[]. This gives a safe default for people to use but allows people to remove extra checks if performance is critical in a section.

@wesm
Copy link
Owner Author

wesm commented Oct 24, 2016

Yeah, having checked/unchecked functions is probably the easiest thing. You can use C++ exceptions for errors that you want to propagate to the user, but not for routine internal "failures" (e.g. key not found). You would want to throw an exception if a malloc fails, for example, but not for boundschecking. Likely most things like boundschecking in internal methods will be verified with DCHECKs and then disabled in release builds. Any code that's being directly exposed to users can raise up exceptions into Pythonland (either raised from libpandas or checked/raised from the wrapper layer, e.g. Cython)

@wesm wesm added this to the stage-1 milestone Dec 8, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants