Hi Mateusz,
Analyzing your idea...
In ideal world, I'd like to see SOCI reporting bugs through a
> dedicated error context.
> Such context would carry values, backend-sourced error message, error
> status, etc.
> Then, users can supply their own streams accepting it:
>
> operator<<(std::ostream& os, soci::error_context const& ec)
>
>
Or user can provide a customized implementation of
[error_context::to_string] which could be called by the operator above.
You probably already had this in mind.
> This way, formatting is completely separated from actual data.
>
> >From usability POV, error context could be carried/used by exceptions too.
> >From different POV, its better to keep exceptions lightweight
> (some 'schools' even suggest "no memory allocation" in exceptions).
>
> Anyhow, it may be worth to consider it.
>
>
I like your idea, I think it would be great to have that much information
when an exception is thrown.
Regarding the allocation, what can be done to avoid allocating and
potentially copying data is holding a pointer to statement_impl (+1
reference) while keeping all relevant data inside it (what I think it's
already true).
One concern of this solution might be extending the statement lifetime to
the exception one.
What this solution doen't address is my current need: successful executions.
I need soci to help me (preferably during log) with queries and their
parameters values.
> I meant context indicating what's the real problem, so we can avoid
> errors aliasing leading to confusions like this one
> https://github.com/SOCI/soci/issues/116
>
>
It's really an annoying situation.
> Yes, I mean that too, see soci::error_context idea above, but also this:
> - what SOCI operation failed (which public interface call failed)
> - error may come from different levels:
> -- SOCI core (i.e. SQL and placeholders parsing)
> -- SOCI backend (i.e. data conversion)
> -- DBMS client library used by SOCI backend (i.e. PQexec failure)
> Only in the last case we have to worry about DBMS-specific
> error message/status code.
>
> Indicating which level of the infrastructure failed makes error reporting
> more meaningful.
>
>
Got it. Your levels make sense.
> Sure, but first there has to be errors reporting infrastructure
> (implemented
> with possible logging in mind, as errors can be logged).
I see the some of my code is still useful for this goal.
It's the basic support for having the string representation of the current
parameter values.
> Once that is ready, we can add logging of non-error information,
> as extension to errors logging.
>
Once the final code only will make it on 4.0.0, IMO the order of the
implementation is not that important.
We can either implement over my current code or merge it later as a part of
a mostly complete error infrastructure. Either way, I'm fine.
I'm still improving my solution I think it can be interesting non-official
support for accessing the parameters values (think boost vault).
So advanced users of 3.2.1 who can't wait for 4.0.0 can have a lightweight
implementation (more according the VZ suggestions).
> Finally, we can make it all configurable (two logging levels should
> enough: errors and info)
> and optional (loging ON and OFF).
> Logging levels + ON|OFF makes a few useful combinations possible.
>
>
This is a must have feature.
> Good question. I said, ideally, so if we can achieve it easily, then why
> not,
> but I wouldn't die-hard for that feature.
>
>
I think the same way.
Regards,
Ricardo
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
soci-devel mailing list
soci-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-devel
