odbx_error_type(3)

💅 odbx_error_type(3) — OpenDBX manual, bestie edition 🎀

Okay so this is a page from the OpenDBX manual set, and it's about odbx_error_type(3) — literally the vibe check for your error codes ✨

---

🌸 NAME 🌸

odbx_error_type — returns the severity of an error 💖

---

✨ SYNOPSIS ✨

#include <opendbx/api.h>

int odbx_error_type (odbx_t* handle, int error);

---

🦋 DESCRIPTION 🦋

So odbx_error_type() is literally giving you the tea on how serious the error code is — the one that the last function call handed back to you through the error parameter. It's how you tell the difference between a critical error and a little warning, so your app can react the right way instead of just panicking 😌

The way it works: if it's a warning, your application can usually keep going — just tell the user what happened and deal with it up on the application-logic level, no drama. But if it's a severe error, bestie, you always have to recreate the connection. No exceptions. 💀

And heads up — in both cases, all the errors that got returned get overwritten the moment the next odbx_*() function is called. So don't get attached to them 🫶

Also, this function has been available since release 1.1.2, iykyk.

Let's take odbx_query() (or literally any other function) as the example, and say it returned an error. If the return value of odbx_error_type() is negative, you've hit a severe error — like the connection to the server is broken 😭. In that case you have to call odbx_unbind(), odbx_finish(), odbx_init() and odbx_bind() in this order to recreate the connection. Otherwise, if the return value was positive, your statement might just have been not understood by the database server. And that's lowkey fine — here you can keep sending the next statement to the server with no need to recreate the connection at all 💅

Now about the handle parameter: it's the connection object that odbx_init() created and returned if the call was successful, and it becomes invalid as soon as you've supplied it to odbx_finish(). Iconic, honestly.

But anyhow — it isn't necessary to supply a valid handle for errors that use error codes not equal to -ODBX_ERR_BACKEND. Which means it's totally possible to use odbx_error_type() even if odbx_init() returned an error 🌈. Though if -ODBX_ERR_BACKEND is supplied in that case nevertheless, the return value will indicate a critical error. Periodt.

Also, all values returned by odbx_*() functions can be fed directly via the error parameter into this function. If the given value doesn't indicate an error, the returned code will always be zero for successful completion. Negative values get separated into classes for critical errors and warnings instead ✨

---

👑 RETURN VALUE 👑

On success — i.e. if ODBX_ERR_SUCCESS or a positive value is supplied as the value of error — the function returns zero. Otherwise, there will be positive and negative values returned, depending on the severity of the error that occurred. Let's break it down:

• Positive values (values greater than zero) — these indicate recoverable errors that leave the database connection intact 🫶. An example might be a warning if a record couldn't be inserted into the table for any reason. In this case, further statements can be sent to the database server and they are likely to succeed. Slay.
• Negative values (values less than zero) — if one of these comes back, a severe error has happened in the backend module, the native database client library or the database server 😭. The connection to the server might be lost, or an out of memory condition might have occurred. This means all further calls to the OpenDBX library will probably fail, and the only way to recover from this situation is to clean up the connection by using odbx_unbind() and odbx_finish() and trying to create a new connection from the ground up. Full reset, main character energy only 💅

---

🙈 ERRORS 🙈

This function doesn't return any errors. Not a single one. Fr fr 🎀

---

🔥 SEE ALSO 🔥

• odbx_finish()
• odbx_init()
• odbx_unbind()

---

✿ and that's the whole page, bestie ✿

This little gem comes from OpenDBX, dated 6 February 2026 — go forth and check those error types, you've got this 💜🦋🌸