pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2652976790
As a general data point for this discussion, I would mention the case of the
Arrow C++ CSV parser. Arrow C++ uses a `Status` class (but `std::expected`
would be similar) for error rep
zhjwpku commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2614827285
I've create a PR #40 to backport std::expected, I'm looking forward to
hearing all of your feedback.
--
This is an automated message from the Apache Git Service.
To respond to the
ormandi commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2611038063
> Because any consumer of libiceberg would have to be careful about API/ABI
conflicts with other Abseil-using libraries.
Thank you for the response! Though, I think API-wise `a
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2610932803
> > A hard public API dependency on Abseil would be a very bad idea IMHO.
>
> Was wondering why do you think so? (just curious)
Because any consumer of libiceberg would ha
ormandi commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2610692481
> A hard public API dependency on Abseil would be a very bad idea IMHO.
Was wondering why do you think so? (just curious)
--
This is an automated message from the Apache
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2610477700
A hard public API dependency on Abseil would be a very bad idea IMHO.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub
ormandi commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2610408311
+1 for Status/StatusOr/`RETURN_IF_ERROR`/`ASSIGN_OR_RETURN` combo (more
about some of these: https://abseil.io/docs/cpp/guides/status). In fact, I'd
probably just depend on these:
lidavidm commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586797954
I'll say I personally find it easier to debug code with exceptions (`catch
throw` vs having to carefully figure out the right breakpoint), though on the
flip side if we do end up wi
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586798062
Hmm... apparently `std::exception_ptr` doesn't allow accessing the
underlying exception object, except by re-throwing and then catching it?
--
This is an automated message from the
lidavidm commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586787439
There is std::current_exception/std::rethrow_exception, though it has some
intricacies. (And I don't think there's anything like ExceptionGroup in Python.)
--
This is an automated
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586537552
I went looking around for comparisons of exceptions and `std::expected` and
I found an insightful tidbit here:
https://www.foonathan.net/2017/12/exceptions-vs-expected/
> [Exce
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586528962
Ah, by the way, a nice consequence of using exceptions is that you can throw
them from constructors, while with `std::expected` you would have to define
`static` factory functions ins
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586497725
Well, you can find a `std::expected` backport for C++20, for example
https://github.com/zeus-cpp/expected
--
This is an automated message from the Apache Git Service.
To respond to
gaborkaszab commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586483772
I'm hesitant to introduce a dependency for C++23. Some projects might not
move that fast and we'd make the adoption hard for them.
I'd still go for using exceptions rather. It
lidavidm commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586312129
(FWIW, I believe the...expected...way of using std::expected when there is
no return value is `std::expected`. You could always `using Status
= expected` + `using Result = expected`
zhjwpku commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2586231279
While looking the std::expected usage, I'm thinking no matter we choose the
std::expected way or Arrow's Result way, it is no harm that we add a Status
data structure, it's useful in
zhjwpku commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2581605188
> > I came across this `expected`[0] class which seems conform to the idea
of Status/Result, but it's in c++23.
> > [0] https://en.cppreference.com/w/cpp/utility/expected
>
wgtmac commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2581572706
> I came across this `expected`[0] class which seems conform to the idea of
Status/Result, but it's in c++23.
>
> [0] https://en.cppreference.com/w/cpp/utility/expected
I
mapleFU commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2547519056
Personally I think if iceberg-cpp is just for parsing the metadata, all is
ok for me. If it's also able to handle the dataset layer, I think exception
might making maintaining the in
zhjwpku commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2547432101
Facebook's Folly has a Expected class [0], Google's Abseil has a StatusOr
class [1] all for the same purpose.
[0] https://github.com/facebook/folly/blob/main/folly/Expected
zhjwpku commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2547406513
I came across this `expected`[0] class which seems conform to the idea of
Status/Result, but it's in c++23.
[0] https://en.cppreference.com/w/cpp/utility/expected
--
This is
wgtmac commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2545956079
As an Arrow developer who has experienced both status and exception in the
same repo, I feel inclined to use exception to make the code shorter and easier
to debug. It is preferred (p
pitrou commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2545841290
The main thing I like about the "Status" style is that it makes error
propagation and handling (or lack thereof) explicit. However, I have no
religious preference :)
--
This is an
23 matches
Mail list logo
