bindings/C: we need seperate opendal_operator_new and opendal_operator_init

[jiaoew1991]

The current opendal_operator_new function contains both the construction of the operator and initialization logic. However, the error in the initialization logic is not returned to the upper layer, and all internal errors in opendal core are being swallowed, which is not conducive to troubleshooting. It is hoped that it can be split into two separate functions.

[Xuanwo]

I think the problem here is that we assume opendal_operator_new will always succeed. However, it doesn't. We should return an error for opendal_operator_new.

cc @Ji-Xinyou

[xyjixyjixyji]

I will take a look

[xyjixyjixyji]

Now, opendal_operator_new() will return a nullptr on error. Splitting it to two functions I think will not be helpful since at least one of them will return a nullptr.

Currently, we only have errorcode for opendal c binding, each error code matches an error kind such as Unexpected, Unsupported, NotFound, ConfigInvalid, etc.

Is adding this will suffice or a more straight-forward error message is preferred.

\cc @jiaoew1991 @Xuanwo

[Xuanwo]

Splitting it to two functions I think will not be helpful since at least one of them will return a nullptr.

I also believe that dividing it into two functions is not beneficial.

Is adding this will suffice or a more straight-forward error message is preferred.

Can we modify our opendal_code struct to include an error message? Users might also want to be informed about any issues that occurred during file reading or writing.

[xyjixyjixyji]

Can we modify our opendal_code struct to include an error message? Users might also want to be informed about any issues that occurred during file reading or writing.

I believe this is possible, this has a drawback that now opendal_code has a heap-allocated message (a string). And users need to deallocate them manually.

IMO this is worth it. What do you guys think?

[jiaoew1991]

opendal_operator_new() will return a nullptr on error

Just returning a nullptr is not enough for diagnosing errors, especially when the authentication configuration of object storage is complex. If there is a misconfiguration, it is necessary to know the detailed error message in order to make modifications. This will be more user-friendly for maintenance.

In addition, adding a message to opendal_code is a good idea.

[Xuanwo]

Maybe we should name it as opendal_error after adding error message?

[xyjixyjixyji]

Maybe we should name it as opendal_error after adding error message?

I agree, I will try to implement that in the following days.