zhjwpku commented on PR #8: URL: https://github.com/apache/iceberg-cpp/pull/8#issuecomment-2543408428
> I think this PR makes too much assumptions that we will go with everything that the Arrow community chose. For instance this seems to decide the "exceptions vs status codes" question. Also decides which test framework to use, and additionally pulls in a number of macros too. I think at this point we should start conversations on these topics, maybe on the Slack channel or as github issues. > > I myself planned to come up with the headers for basic classes like Catalog Table and such, but I'd personally prefer exceptions over status codes for many reasons. Method chaining is something I find really powerful in the Java implementation but with status codes you wouldn't be able to do that if you have to check the status for every function call. Not to mention that constantly checking for statuses would make the code less readable. Also Statuses would make the parameter list longer, not to mention that lines would be longer (which somewhat matters now that we went for 90 chars). > > Long story short I'm -1 for this PR. I have seen some use cases of Method chaining in C++ world, mostly people use it for constructing object I guess. Can you elaborate how we can use it with exception to make the apis easy to use? I don't like method chaining, it makes debug more difficult, when you set a breakpoint on the method chain and exception happens, how do you know which call give out the exception? I think it's generally good practice to always write very short and concise lines. Every line should just make one method call. There is an old stackoverflow question which I think we can take a look, [Method chaining (fluent interfacing) - why is it a good practice, or not?](https://stackoverflow.com/questions/1103985/method-chaining-fluent-interfacing-why-is-it-a-good-practice-or-not) -- 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 unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
