Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sqlite error log? #109

Closed
bstarynk opened this issue Apr 22, 2017 · 6 comments
Closed

sqlite error log? #109

bstarynk opened this issue Apr 22, 2017 · 6 comments

Comments

@bstarynk
Copy link

bstarynk commented Apr 22, 2017

It would be nice to be able to interface with sqlite3_config for error logging with SQLITE_CONFIG_LOG.

Perhaps we would want to be able to code

sqlite::error_log([&](int errcode, const char*msg) {
  std::clog<<"SQLITE ERROR " << errcode << ":" << msg << std:endl;
});

What do you think?

I might provide a small patch if we agree on that API.

Thanks.

Basile Starynkevitch : basile at starynkevitch dot net
(France)

@bstarynk bstarynk changed the title sqlite log? sqlite error log? Apr 22, 2017
@aminroosta
Copy link
Collaborator

@bstarynk I think we should somehow use our sqlite::exceptions namespace.
We don't want users figuring out error_type from error_code.

A simple solution may be:

sqlite::error_log([](sqlite_exception e) {
     cerr  << e.get_code() << ": " << e.what() << " during "
	      << e.get_sql() << endl; // Now we also have .get_sql() :-)
});

I am also wondering how can we efficiently overload that function on exceptions from sqlite::exceptions namespace. @zauguin :-)

sqlite::error_log([](sqlite::exceptions::internal e) { });
sqlite::error_log([](sqlite::exceptions::full e) { });
// ...

@zauguin
Copy link
Collaborator

zauguin commented Apr 22, 2017

I think it would be easier to specify all overloads in a sigle call, like

sqlite::error_log(
    [](sqlite::exceptions::internal e) {
      // Do sth.
    }),
    [](sqlite::exceptions::full e) {
      // Do sth.
    }),
    ...
    );

Otherwise we would need some kind of runtime list for this.

This can easily be implemented on top of the basic functionality. Anyway .get_sql() will return an empty string, because AFAICT the current SQL statement is not available.

@aminroosta
Copy link
Collaborator

@zauguin Looks perfect to me 👍

@bstarynk What do you think, does zauguin api works for you?

@bstarynk
Copy link
Author

I am not sure to follow you. It looks you think of C++ exceptions.
I was just thinking of adding an error log function.

@aminroosta
Copy link
Collaborator

@bstarynk

sqlite::error_log([&](int errcode, const char*msg) {
  std::clog<<"SQLITE ERROR " << errcode << ":" << msg << std:endl;
});

With this interface we need to check errorcode to determine the type of an error / exception.

For each sqlite error message we have a corresponding class in sqlite::exceptions namespace.
The sqlite::exceptions::* classes have both errorcode and msg.

In addition to sqlite exceptions we also have some exceptions for invalid use of the library like sqlite::exceptions::more_rows, ::no_rows, ::reexecution and ::mroe_statements.

So my suggestion is to pass the exception object itself to the new sqlite::error_log() function.
We also can overload on the exception type.

@aminroosta
Copy link
Collaborator

@bryant1410 also take a look at @zauguin implementation #110

This was referenced Apr 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants