TileDB Error's are not actionable

[jakebolewski]

Currently when using the C-API there is no way to tell what the error was (class) without parsing the error string.

[stavrospapadopoulos]

In addition to refactoring error handling, all C API functions should return a tiledb_err_t object instead of int. We can then add extra functions to act on tiledb_err_t objects.

[jakebolewski]

I don't know any C Api that does it this way? Do you have an example.

I was thinking of sticking to Posix semantics here and for more fine grained error handling implementing it in a way similar to libgit2.

Ex:
tiledb_error_last() -> tiledb_error_t
tiledb_error_message(tiledb_error_t*)
tiledb_error_class(tiledb_error_t*) -> Error Class Enum
tiledb_error_code(tiledb_error_t*) -> Error Code Enum (per class)

[jakebolewski]

Wrong link, updated.

[stavrospapadopoulos]

I like it, let's do that.

[jakebolewski]

This issue needs a bit more work in order to be closed:

• define a c api for getting the message, error class, and error code from an error object
• a thread safe stack for consolidating all error's returned from all threads per operation
• a c api for iterating over possibly all error's returned after a given api call

[stavrospapadopoulos]

Currently we save the status errors in a (created) context. Some C API functions do not take the context as input (e.g., all tiledb_config functions, in the future all tiledb_array_schema functions, etc.) . How do we get the status error in these cases?

[jakebolewski]

If you are configuring a ctx then I don't see why you cannot add that as an attribute to `tiledb_config`. Standalone array_schema's seem useful, but again I think you could do validation as part of adding to a specific context and then have a function for retrieving an opaque handle to an already validated schema object.

…

On Sun, Jul 9, 2017 at 10:54 AM, Stavros Papadopoulos < ***@***.***> wrote: Currently we save the status errors in a (created) context. Some C API functions do not take the context as input (e.g., all tiledb_config functions, in the future all tiledb_array_schema functions, etc.) . How do we get the status error in these cases? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGqphaUvyqEX0lF4FNT37PF20W-FIl5ks5sMQXegaJpZM4N7p8f> .

[stavrospapadopoulos]

This means that every single API function will take the context as input. Are you ok with this?

Moreover, please check how to handle the error of initializing a storage manager in tiledb_ctx_create. If this init fails, the user cannot capture it (it will just get a nullptr for the returned ctx).

[stavrospapadopoulos]

Taking another look, I think that we should have a uniform approach. Currently, ctx is attached to only some of the functions. Perhaps we should have it as input everywhere?

[jakebolewski]

I guess I am arguing for consistency in threading the ctx. Otherwise the only way to do this (that I see) is to have a global error state. The only way to disambiguate which from which context an error was thrown would be to provide it so I don't see what you gain.

Maybe there is a cleaner design, but I think associating error's with a given context is the simplest.

[jakebolewski]

You can guarantee (well pretty much) that construction of a valid Storage Manager object will succeed. If during initialization (init) of the storage manager an error is thrown you can still associate it with a valid ctx object, so I don't see the problem.

[stavrospapadopoulos]

In the rest of the API, when an error occurs, a TILEDB_ERR is returned, whereas here we return null or a valid context. So how does the user gets notified about the error? I'll check on wherher initing the storage manager can always succeed.

[jakebolewski]

change the api to take a pointer to a tiledb_ctx_t?

…

On Mon, Jul 10, 2017 at 9:51 AM, Stavros Papadopoulos < ***@***.***> wrote: In the rest of the API, when an error occurs, a TILEDB_ERR is returned, whereas here we return null or a valid context. So how does the user gets notified about the error? I'll check on wherher initing the storage manager can always succeed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGqpv86NqAejiCMBip_8ou5c8cPSg_hks5sMkiegaJpZM4N7p8f> .

[stavrospapadopoulos]

Hehe sure, but then it is not consistent with all the other 'tiledb_*_create' functions. I may have to change all of them, which is not too bad.