> Really, a mysql driver? Are you basing it on libdrizzle? How is it working > out?
Unfortunately not libdrizzle, as it would probably take me 10* more to test against the servers I want to use. At the end it does not seem to be a big deal writing the driver once it is defined what is needed. There were some small design difficulties as mysql handles the binding at row granurality, but Db::Wto is calling the binds at column granularity. It would probably make sense to define some tuple bind methods, where the full raw could be bound etc. I will test it the comming days, and I will probably release it as part of the babelengine.org project. I hope you do not mind it. I think we should find some agreements that babelengine.org and wt will work together without "friction"... >>>> 2. Doing DB operations on constructors (SqlStatement, SqlConnection) >>>> is maybe not the best idea, as it makes exception handling, >>>> deallocation etc. generally difficult. What happens if a driver throws >>>> an exception on these constructors? >>> >>> I believe throwing exceptions from a constructor is perfectly fine ? >>> (http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2) >> yes... but what you quoted tries to say the same... better to avoud... >> but read here.. (pasted at the end of the email) > So their argument is based on "We do not use C++ exceptions." > > I am not going to open the exception debate, but, I tend to find them > useful, especially to signal problems in situations like these where > you interface with a database and pretty much everything can go wrong > during every call. Me neither... just based on my experience, it is better to avoid heavy initialisation on a constructor. Initialising db libraries, creating connections etc. falls a bit in that area... But as I said it is not a strong opinion. > Also, please consider their reasoning: > > "On their face, the benefits of using exceptions outweigh the costs, > especially in new projects. However, for existing code, the > introduction of exceptions has implications on all dependent code. If > exceptions can be propagated beyond a new project, it also becomes > problematic to integrate the new project into existing exception-free > code. Because most existing C++ code at Google is not prepared to deal > with exceptions, it is comparatively difficult to adopt new code that > generates exceptions." > I do not think we need to integrate with existing exception-free code, > and if we do, it is usually a web application that will call API from > another library, not vice-versa, so the propagation argument does not > hold. Well... yes and no... but if it will be a big problem, tuning can be done at a later moment.. > And if you do use exceptions, then there is no reason not to use them > from within a constructor (you cannot use them destructors, but they > are encouraged for failing in a constructor as per the C++ FAQ). >> Well... actually my problem is about knowing that after constructor it >> is usable. But this could be marked with some extra state "unusable". >> The constructor, or any other operation could set the connection and >> statement to an "unusable state" (I am reffering to the existing >> states defined in the sqlstatement) > > After a constructor, your object should either be usable, or not > constructed at all (i.e. an exception was thrown). Please do not add > an "unusable" state to a constructor. this unusable is more like the zombie proposed on the c++faq... But I do not like the idea neither.. The reasoning behind is that if one writes a low level plugin (like the backend), it should be as less harmful as possible in case of errors. Connection might fail, so it is not a real exception. But throwing an exception means nothing could be constructed. So it is rather a boundary case.. blah blah :) Some upper level (like Wt::Dbo) should test some error condition and send further the "exception" to higher level, if that is the design policy. Throwing an exception means a serious design decision. I did not look at Wt::Dbo if it would cache exceptions. I would let rather Wt::Dbo to decide if exception should be thrown etc. In the Blog example I am affraid if one would replace the backend, the exception would not be caught, and the application would fail.. But caching could happen inside the client application. etc. etc... But again.. Anyway one can still identify good places to do exception handling... So whatever direction I try to look, I think there are no good reasons nor pro, nor contra. Just maybe feeling... Personally I would not throw exception in a very low level library... -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
