|
From: | John W. Eaton |
Subject: | Re: Using exceptions in the core |
Date: | Wed, 07 Oct 2015 18:07:27 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 |
On 10/07/2015 12:17 PM, John W. Eaton wrote:
On 10/07/2015 12:09 PM, Mike Miller wrote:But this is about the same as having, say std::string octave_value::string_value (); // this one throws an exception std::string octave_value::safe_string_value (const std::string& msg) nothrow; Do we want to give the user the option of handling the exception or having error() called for them?Since error throws an exception, both of these would throw exceptions, but the first would just display only the default "wrong-type-argument" message.
Also, since these are error message strings, then maybe we should be defining something like
std::string octave_value::string_value (const char *fmt, ...); ? I've come across at least one instance of something like std::string val = arg.string_value (); if (error_state) { error ("foo %d", n); return retval; } If we only allow string constants, then we'd have to do something like std::ostringstream buf; buf << "foo " << n; std::string val = arg.string_value (buf.string ());I think we can all agree that if it seems odd to pass in an error message that might be used if there is a failure, then it is even worse to have to cobble together some complex message just in case...
Please take a look at the attached patch for a version that uses the fmt and va_arg approach.
jwe
string-value-diffs-v2.txt
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |