Xuanwo commented on PR #1861: URL: https://github.com/apache/incubator-opendal/pull/1861#issuecomment-1500096543
> 2\. The two-stage API you propose is no doubt a good practice to propagate error, my idea will be APIs like Good idea. I do think we need some builder things in c bindings too. But we can leave this to further PRs. Python/Node.js/Java has similiar problems too. Maybe we should do some code generation to address this issue. And for now, I think it's Ok to have a `opendal_operator_new(void)` (just for memory service). > * The problem is about the `ErrorKind` definition in `core`, since it is attributed by `#[non_exhaustive]`. I suggest **remove that attribute** so that every update on the `od::ErrorKind` will let all bindings' compilation fail, working as a reminder for bindings update. No, this error kind is `non_exhaustive`. It's part of our public API. Bindings should handle all error kinds. And everytime we add a new error, we should update all bindings. It's not a heavy work and we won't add new kinds every day. > * This is tricky, I think we may leave the error message to further PRs. Yep, agreed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
