(Apology for delay, unfortunately I expect more until mid/end of June or so :))
On 21 April 2013 12:29, Ricardo Fabiano de Andrade <ricardofabianodeandr...@gmail.com> wrote: > Mateusz Loskot <mate...@loskot.net> wrote: >> 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. Good idea. I haven't thought about it :) >> 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. I'm glad you second it. > 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. If we stick to the basic guidelines from Boost, we shouldn't worry about memory intensive operations http://www.boost.org/community/error_handling.html > 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. Yes, it does not, yet. It does give you tools ready to use to achieve what you need: logging. So, the rest would be to add infrastructure for values capturing and to add logging to functions of core/backends, using the facilities delivered in previous steps. I agree, the two, errors and logging, are orthogonal and they can be implemented in any order. I guess, if we have both first, then logging of errors would make a very good evaluation of logging and allow to capture problems before moving into more complex topic of logging SQL details. On the other hand, as usual, it will be"first required, first implemented" sequence. >> 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. I admit, I haven't looked at your code yet. But it sounds good. Although in exceptions, I'd try to keep string formatting to minimal, see Boost guidelines linked previously. >> 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. Indeed, as I reflected above. > 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). Great idea. I always wanted to allow SOCI extensions with simple way to integrate into build (in Boost, I simply copy two folders and I'm done, builds work). I have to say, lots of major things are on the place. Tough to decide which one to work on first :) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ soci-devel mailing list soci-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/soci-devel
