[lexical_cast] A non-throwing lexical cast? [Was: 5 Observations - My experience with the boost libraries]
On Wed 24/03/10 03:40 , Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman wrote:
... All I'm saying is that in the real world, most projects are mixed C/C++ and that the needs of both communities need to be addressed if boost is going to remain relevent.
For the sake of not arguing, let's assume that your assertion is true. Let's hear your *actionable* proposal for improving boost. E.g. show us the better interface for <insert Boost library here>
Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice. If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse": - boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.
Qua, 2010-03-24 às 09:31 +0000, pete@pcbartlett.com escreveu:
On Wed 24/03/10 03:40 , Jonathan Franklin <franklin.jonathan@gmail.com> wrote:
On Tue, Mar 23, 2010 at 9:31 PM, Tom Brinkman wrote:
... All I'm saying is that in the real world, most projects are mixed C/C++ and that the needs of both communities need to be addressed if boost is going to remain relevent.
For the sake of not arguing, let's assume that your assertion is true. Let's hear your *actionable* proposal for improving boost. E.g. show us the better interface for <insert Boost library here>
Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice.
If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse":
- boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.
Why? Is it because you need to do some cleanup? Do you known what RAII is?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote:
Qua, 2010-03-24 às 09:31 +0000, pete@pcbartlett.com escreveu:
Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice.
If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse":
- boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.
Why? Is it because you need to do some cleanup? Do you known what RAII is?
Exception translation, i.e. "re-thrown" as in "thrown in a different form". boost::bad_lexical_cast is not derived from my_project::invalid_user_input o or whatever. This happens a lot with boost::lexical_cast.
Kim Barrett wrote:
On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote:
Qua, 2010-03-24 às 09:31 +0000, pete@pcbartlett.com escreveu:
Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice.
If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse":
- boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown. Why? Is it because you need to do some cleanup? Do you known what RAII is?
Exception translation, i.e. "re-thrown" as in "thrown in a different form". boost::bad_lexical_cast is not derived from my_project::invalid_user_input o or whatever. This happens a lot with boost::lexical_cast.
So a possible improvement to the lexical_cast design would be to have an optional template arg specifying the exception to throw for errors? Or perhaps some other general/global way of lexical_cast looking up an exception to throw instead of the ones it does? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Hi, Rene Rivera wrote:
Kim Barrett wrote:
On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote:
Qua, 2010-03-24 às 09:31 +0000, pete@pcbartlett.com escreveu:
Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice.
If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse":
- boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown. Why? Is it because you need to do some cleanup? Do you known what RAII is?
Exception translation, i.e. "re-thrown" as in "thrown in a different form". boost::bad_lexical_cast is not derived from my_project::invalid_user_input o or whatever. This happens a lot with boost::lexical_cast.
What about boost::system::error_code as the second parameter for the non throwing version? And it does not suffer from the return error code problem. Just take a look at boost::filesystem and boost::asio.
So a possible improvement to the lexical_cast design would be to have an optional template arg specifying the exception to throw for errors? Or perhaps some other general/global way of lexical_cast looking up an exception to throw instead of the ones it does?
On Mar 25, 2010, at 2:17 PM, Bruno Santos wrote:
boost::lexical_cast - throws. Almost always needs to be caught and re-thrown. Why? Is it because you need to do some cleanup? Do you known what RAII is?
Exception translation, i.e. "re-thrown" as in "thrown in a different form". boost::bad_lexical_cast is not derived from my_project::invalid_user_input o or whatever. This happens a lot with boost::lexical_cast.
What about boost::system::error_code as the second parameter for the non throwing version? And it does not suffer from the return error code problem. Just take a look at boost::filesystem and boost::asio.
The point was that the present interface for boost::lexical_cast often leads to try/catch blocks. I like this suggestion of a second error_code argument a lot.
or boost::lexical_cast_no_throw() On Thu, Mar 25, 2010 at 11:57 AM, Kim Barrett <kab.conundrums@verizon.net> wrote:
On Mar 25, 2010, at 2:17 PM, Bruno Santos wrote:
boost::lexical_cast - throws. Almost always needs to be caught and re-thrown. Why? Is it because you need to do some cleanup? Do you known what RAII is?
Exception translation, i.e. "re-thrown" as in "thrown in a different form". boost::bad_lexical_cast is not derived from my_project::invalid_user_input o or whatever. This happens a lot with boost::lexical_cast.
What about boost::system::error_code as the second parameter for the non throwing version? And it does not suffer from the return error code problem. Just take a look at boost::filesystem and boost::asio.
The point was that the present interface for boost::lexical_cast often leads to try/catch blocks.
I like this suggestion of a second error_code argument a lot.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Tom Brinkman wrote:
boost::lexical_cast_no_throw()
Or.. template <typename T, typename S> T lexical_cast(const S & arg, const T & error_default_value); -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
Tom Brinkman wrote:
boost::lexical_cast_no_throw()
Or..
template <typename T, typename S> T lexical_cast(const S & arg, const T & error_default_value);
FYI, IIRC, there is a String Convert library by Vladimir Batov in the review queue that addresses short comings of lexical_cast, providing [no]throw variations along with the ability to specify a default value. There was significant discussion in previous threads leading to this library development. Jeff
Rene Rivera <grafikrobot <at> gmail.com> writes:
Tom Brinkman wrote:
boost::lexical_cast_no_throw()
Or..
template <typename T, typename S> T lexical_cast(const S & arg, const T & error_default_value);
I've implemented later in my own version of lexical cast. In 99% of the time this is exactly what I need: either convert string to number or take this default value. Another good consequence is that I do not need template parameter anymore. Gennadiy
Hi, Kim Barrett wrote:
On Mar 24, 2010, at 5:20 PM, Bruno Santos wrote:
Qua, 2010-03-24 às 09:31 +0000, pete@pcbartlett.com escreveu:
Taking an example from way back at the start othis thread, in my personal experience a non-throwing version of lexical_cast<> would be very nice.
If I look at the cases where I pass user data through my libraries into boost libraries without some pre-validation, there are very few, and naturally these are the cases where the validation would as difficult as the "parse":
- boost::spirit::phrase_parse - Just returns a true/false, and I build a nice context-driven error message myself if necessary. - boost::lexical_cast - throws. Almost always needs to be caught and re-thrown.
Why? Is it because you need to do some cleanup? Do you known what RAII is?
Exception translation, i.e. "re-thrown" as in "thrown in a different form". boost::bad_lexical_cast is not derived from my_project::invalid_user_input o or whatever. This happens a lot with boost::lexical_cast.
If the user data is data that comes from a file or user interface, I agree in your assertion. However, if it's from someone using your library, it's an obvious programming error, doing exception translation in this case is pointless. Anyway, in my opinion, passing a boost::system::error_code as the second parameter for a non throwing version would be the best solution.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (7)
-
Bruno Santos -
Gennadiy Rozental -
Jeff Flinn -
Kim Barrett -
pete＠pcbartlett.com -
Rene Rivera -
Tom Brinkman