Ji-Xinyou commented on PR #1861:
URL:
https://github.com/apache/incubator-opendal/pull/1861#issuecomment-1500085894
Hi @Xuanwo , I think carefully about the so called `error` thing and have
several things want to discuss.
1. The API of `opendal_operator_new`
* You proposed a two-stage API for building an `operator`, I have
following thoughts on that.
* IMO the API you proposed means that `operator_new` returns a
operator_ptr stores necessary information to `build` a `operator_ptr` with
which we use `operator_build` to further build it and return the error code. I
think the `operator_ptr` should only stores the pointer to the actual `operator`
* Therefore, I have some ideas on this problem for this PR.
1. For this PR, we just merge the `operator_new` function,
which returns a `operator_ptr`. If anything fails, the `operator_ptr` will
point to NULL.
2. The two-stage API you propose is no doubt a good practice
to propagate error, my idea will be APIs like
```C
struct opendal_operator_builder* opendal_operator_new(char* scheme);
opendal_code opendal_operator_build(opendal_operator_builder* builder);
struct opendal_operator_builder {
struct opendal_operator_ptr ptr;
char* scheme;
...
}
```
let the builder stores the actual `operator_ptr`, which will further be used
by user.
2. The pattern matching of `od::ErrorKind`
* 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.
3. The error message design
* This is tricky, I think we may leave the error message to further PRs.
--
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]
