Open wesm opened 7 years ago
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.
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)
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.