Boost C++ Libraries: Ticket #7063: try_unhex() that doesn't throw on bad input

Marshall Clow — Tue, 17 Jul 2012 20:06:49 GMT

unhex already returns a value; the output iterator (so that you can chain operations).

Wed, 18 Jul 2012 12:47:07 GMT

I know. This request is for something like bool try_unhex(const T& in, U& out) Having to wrap unhex() into a try/catch block is quite cumbersome and sometime exceptions can't be used at all.

Marshall Clow — Mon, 24 Sep 2012 16:59:45 GMT

Something like this?

Of course, it will still throw if a memory allocation fails. Or the output iterator throws. Or the input iterator throws. Or one of the assignments throw.

   template <typename InputIter, typename OutputIter>
   bool try_unhex ( InputIter first, InputIter last, OutputIter out ) {
      try {
         (void) unhex ( first, last, out );
         return true;
         }
      catch ( const hex_decode_error & ) {}
      return false;
      }

Note:

if you pass the output iterator by value, then you lose any changes that are made.
If you pass the output iterator by reference, then you can't use an unnamed temporary (such as the result of std::back_inserter)

In any case, I'm not convinced that this is a good idea.

Thu, 27 Sep 2012 08:27:46 GMT

No, I was thinking of range-based input and container-based output. Like this:

std::string a = unhex("ABCD"); // may throw on bad input
std::string b;
if (!unhex("ABCD", b)
  return ERROR;

Marshall Clow — Thu, 27 Sep 2012 13:16:37 GMT

Olaf --

Thinking some more about this, I don't think this belongs in boost, but rather in your application code.

It throws away useful information, a big no-no in generic code. (The cause of the failure, and the point of failure)

Of course, in your specific use case, throwing away this information (or reducing all failures to a single bit) may be perfectly fine, and that's why it should live in your code.

Thu, 27 Sep 2012 13:28:32 GMT

The point of failure (in the input stream) isn't available anyway, is it?

Marshall Clow — Thu, 27 Sep 2012 13:52:22 GMT

Not directly:

In the case of "not enough input" the point of failure is the end of the input.
In the case of "non-hex input", the character that caused the error is attached to the exception that is thrown

So you can figure out where the error occurred.

Thu, 27 Sep 2012 14:24:27 GMT

Nice!

It throws away useful information, a big no-no in generic code.

Since it's a new variant, the old variant is still available if that info is required, isn't it?