Feature request: Allow exceptionless usage

[omartijn]

Since using c++20 and coroutines, I'm running more and more into issues because you cannot await a coroutine in a catch-clause. For my code I've now created a wrapper to deal with this, it catches the exception and returns an expected which will have an error on failure:

template <typename Type, unsigned Rapidjson_Parseflags = rapidjson::kParseDefaultFlags>
std::expected<Type, std::string> try_from_json(std::string_view json) noexcept
{
	try
	{
		return json_dto::from_json<Type, Rapidjson_Parseflags>(json_dto::make_string_ref(json.data(), json.size()));
	}
	catch (const json_dto::ex_t& e)
	{
		return tl::make_unexpected(std::string{ e.what() });
	}
}

plus a whole lot of other overloads, of course. It'd be nice to have support for something like this directly inside json_dto. I realize that std::expected is only introduced in c++23 (which would require bumping the c++ version), but we could potentially only do this if compiling with a recent enough c++-version, use a third-party library (something like tl::expected), or implement our own (like we do with json_dto::Optional)

Any ideas on this? I wouldn't mind doing the work if it's something you'd be interested in merging.

[eao197]

Hi!

I just want to clarify: you're speaking about a new family of functions that doesn't throw, but catch exceptions inside and returns something like std::expected instead. Am I right?

[omartijn]

That's the way I implemented it now, but ideally if you bake it into the library itself, then you'd do it the other way - you'd implement the non-throwing variants (that return an std::expected) and have the throwing variants call it, and throw in case the std::expected does not hold a value.

[eao197]

Give me a couple of days, please. I have to review the current implementation and remember important details.

However, do you think that returning std::expected<Something, std::string> from a function that doesn't throw is a good idea? The constructor of std::string could throw std::bad_alloc.

[omartijn]

Well, that's an interesting point. It's theoretically unsafe, that's why a common way is to use std::error_code instead. You can create your own error category with your own messages (which then don't have to be allocated). That's a nice pattern for many cases, but json_dto creates nice messages on the fly indicating exactly what is wrong ("this field failed to deserialize because it's the wrong type").

So, in terms of usefulness, using an std::error_code is worse than we now have, but it'd be allocation-free and thus safe. In my (and I think I am not unique in this at all) case, a failure to allocate a small string is not considered a recoverable error. If we're that low on RAM we're very likely going to crash anyway, so I tend to treat this as something that won't happen.

[eao197]

The std::bad_alloc may be thrown not because of low of RAM, but becases a special allocator was used (for example, an arena-based one with small arena size). So std::bad_alloc in one place doesn't mean that there is no enough RAM and the application can survive. Such std::bad_alloc may be thrown by the constructor of T.

Another possible solution is to return std::expected<T, error_description_t>, where error_description_t could be something like:

struct json_dto_ex_message_t { std::string m_what; };
struct exception_message_t { std::string m_what; };

using error_description_t = std::variant<
  json_dto_ex_message_t /* for the case of json_dto::ex_t */,
  exception_message_t /* for the case of std::exception */,
  std::exception_ptr /* for the remaining cases */
>;

If the construction of json_dto_ex_message_t or exception_message_t throws we can catch an exception and return std::exception_ptr.

Disclaimer. This is just an idea, not a proposal :)

[omartijn]

Well I certainly appreciate the forward thinking here, as I said, what I've been using internally is "good enough for me", but it makes sense that if we want something that works for everyone the requirements will be a bit stricter.

Having a variant be the error-type is of course one option, if we want to keep it simpler we can of course return only the std::exception_ptr, that can then be unpacked again by re-throwing if required.

If we want to go the struct-route, we might return something that has an internal buffer to store the error message, and implements the string_view concept - so it can be used as such. Think begin(), end(), data(), size(), etc... That alleviates the need for allocations (and thus the potential for std::bad_alloc for creating the error itself).

[eao197]

if we want to keep it simpler we can of course return only the std::exception_ptr, that can then be unpacked again by re-throwing if required.

I thought about it, but I don't like that approach because it is too expensive to get error message.

May be something like that:

class error_description_t
{
  std::exception_ptr * m_source_ptr;
  const std::exception * m_exception_view_ptr; // Maybe nullptr.
public:
  error_description_t(std::exception_ptr source_ptr)
    : m_source_ptr{std::move(source_ptr)}
    , m_exception_view_ptr{nullptr}
  {}
  error_description_t(
    std::exception_ptr source_ptr,
    const std::exception * exception_view_ptr)
    : m_source_ptr{std::move(source_ptr)}
    , m_exception_view_ptr{exception_view_ptr}
  {}

  [[nodiscard]] const char *
  what() const noexcept
  {
    if(m_exception_view_ptr) return m_exception_view_ptr->what();
    else return "unknown exception type";
  }

  void
  rethrow() const { ... }
}

In that case we can write wrappers like that:

template <typename Type, unsigned Rapidjson_Parseflags = rapidjson::kParseDefaultFlags>
std::expected<Type, json_dto::error_description_t> try_from_json(std::string_view json) noexcept
{
	try
	{
		return json_dto::from_json<Type, Rapidjson_Parseflags>(json_dto::make_string_ref(json.data(), json.size()));
	}
	catch (const std::exception& e)
	{
		return tl::make_unexpected(
			json_dto::error_description_t{std::current_exception(), &e});
	}
	catch (...)
	{
		return tl::make_unexpected(
			json_dto::error_description_t{std::current_exception()});
	}
}