-
Notifications
You must be signed in to change notification settings - Fork 183
Description
Congratulations on the GA release! 🥳
I've been looking forward to the cuda bindings for a while, and was just looking through the docs.
The overview notes an implementation of ASSERT_DRV
, which already contains the caveat:
In a future release, this may automatically raise exceptions using a Python object model.
I'm not sure if that means that the errors are going to be subclasses of something like a CUDAError
, or if that is to be interpreted some other way, but in any case, I was quite surprised about this choice of exception API
Why not make the functions raise err
by default? Right now, IIUC, every invocation would need to accept an extra err
-return (and handle it with something like ASSERT_DRV
). This seems like a really onerous task to achieve the default behaviour of "fail in case of something unexpected" (and actively choosing where to introduce try... except:
handling to continue even if things fail).
It seems like a bad trade-off for me (high verbosity, and easy to forget adding an ASSERT_DRV
), but maybe I'm overlooking something?
The reasons I'm raising this right now, is that this would be a pretty fundamental API change, and if there's any chance at all (assuming it's not already "zero" after GA), it would be ASAP.