zhjwpku closed issue #14: [DISCUSS] Exceptions vs status codes
URL: https://github.com/apache/iceberg-cpp/issues/14
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscri
zhjwpku commented on issue #14:
URL: https://github.com/apache/iceberg-cpp/issues/14#issuecomment-2772516785
I think we can close this issue for now, we have exception and expected in
our code base, lets see how it works.
--
This is an automated message from the Apache Git Service.
To res
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
25 matches
Mail list logo
