Re: [Development] Make Qt6 JNI API safer to use
On Fri, Mar 06, 2020 at 11:59:32AM +, Simon Hausmann wrote: >Hi, > >I think it would be great to have a result type in the Qt API and use >that, instead of C++ exceptions. In theory we could use std::variant, >but I think the API inconvenient for the use-case of a result. That >wouldn't prevent us from using it in the implementation though. > >Simon The problem with the currently available and sometimes sold as "proper" solutions in C++ is that they require a lot of boilerplate to be written, so people (rightfully...) ignore or even actively refuse to use them. As stated earlier, Rust's Result and question mark operator is a *really* nice solution to that. It's almost no overhead to write and read compared to the "no error checking" solution. Now, if there were only a way to change something in C++ ... Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
Hi Bogdan, first of all, I think improving the JNI error handling is a great idea. However, I'm currently not convinced that we should (unconditionally) require exceptions, or that we really need them. As far as I can tell, the Android NDK still disables exceptions by default, and the last time I checked, enabling them had a non-insignificant size overhead. However, I think we can actually have our cake and eat it. It should be possible if we are going to use something like outcome/QSystemResult. - Our API would always return an outcome type - If there is an error, you just store it that information there. We can introduce our own error codes to distinguish between the different error conditions (pending exception, illegal argument, etc.). If you think we need more context than the type of the error, we could use a full-blown Result type. - If you access the normal value of the result, and exceptions are not enabled, just std::terminate. In addition, if a user decides that they can accept the cost of exceptions, this is the place where you can throw an exception if they are enabled. Regards, Fabian Am 05.03.20 um 13:12 schrieb Bogdan Vatra via Development: Hi, I started to review and move androidextras to qtbase (qtbase/src/corelib/ platform/android). Here we have a problem with our Qt JNI API. The problem is that in Java exceptions are (ab)used everywhere. Even if we have a way to check for exceptions after each call in Qt, it's not used (not even by us in Qt code itself), mostly because it's a little unwieldy to use it. To fix this issue I'd like to discuss with you a few options: 1 - add something similar to std::expected[0] or outcome[1] to Qt. We can't use std::optional because it doesn't work for void function e.g. std::optional callMethod(). std::expected allows our API users to handle the errors without try/catch. I think std::expected will be useful in many places not only for QtJNI e.g. QJsonDocument QJsonDocument::fromJson(const QByteArray , QJsonParseError *error = nullptr) or any other place where we pass the error result as an argument. Of course we still need to enable exceptions as if we try to access the returned value without checking its state first it will still throw an exception if the value is not valid. 2 - use exceptions (at least for android?). This means if a JNI call fails it will throw a C++ exception. IMHO this is by far the best, cleanest and easiest solution. 3 - I'm open for better ideas which makes the coding safer and *easier*. Cheers, BogDan. [0] https://wg21.link/P0323R9 sadly it's not in c++20 :( therefore we need to either use an existing implementation or implement one in Qt. [1] https://ned14.github.io/outcome/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
Hi, I think it would be great to have a result type in the Qt API and use that, instead of C++ exceptions. In theory we could use std::variant, but I think the API inconvenient for the use-case of a result. That wouldn't prevent us from using it in the implementation though. Simon From: Development on behalf of Thiago Macieira Sent: Thursday, March 5, 2020 16:31 To: development@qt-project.org Subject: Re: [Development] Make Qt6 JNI API safer to use On Thursday, 5 March 2020 07:29:07 PST Bogdan Vatra via Development wrote: > În ziua de joi, 5 martie 2020, la 17:21:11 EET, Thiago Macieira a scris: > > On Thursday, 5 March 2020 07:14:44 PST Vitaly Fanaskov wrote: > > > I think something like std::expected is a nice thing to have. > > > > > > There is some experimental implementation of std::expected: > > > https://github.com/TartanLlama/expected. > > > > > > Another good example is Result > > > (https://doc.rust-lang.org/std/result/index.html) type from Rust. But > > > might look clumsy in C++, because there is neither pattern matching nor > > > operator? > > > (https://doc.rust-lang.org/std/result/index.html#the-question-mark-opera > > > to > > > r-> ) to handle this case gracefully. > > > > We have QSystemResult in QtCore already. This predates both std::expected > > and Result from Rust. > > > > One of my abandoned commits (see the I/O thread) was an update to it to > > make it better. > > Where is QSystemResult? I can't find it in dev branch ... Did you rename it? Ah, sorry, we only have QSystemError. QSystemResult is the class I added and abandoned in Idaa189413f404cffb1eafffd14cef83d45089eee. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
Regarding exceptions, I see your point. Personally I agree with using
exceptions here. If there are no well justified objections, just go for it.
On 3/5/20 4:59 PM, Bogdan Vatra wrote:
Hi,
În ziua de joi, 5 martie 2020, la 17:14:44 EET, Vitaly Fanaskov a scris:
I think something like std::expected is a nice thing to have.
There is some experimental implementation of std::expected:
https://github.com/TartanLlama/expected.
That implementation is my favorite, I really like the map, map_error,
and_then, or_else additions ;-) .
[...]
Regarding using exceptions, well, I would vote for this option, but I
don't think that this is possible at all to convince people to use
exceptions in this module.
A single Qt JNI call might fail in different places, e.g.:
auto str1 = QAndroidJniObject::callStaticObjectMethod("MyClass",
"fromNumber",
"(I)Ljava/lang/String;",
10);
1. check if there is any pending exceptions on current JNI Env
2. check if the method signature is okay
3. check if the method call throw any exceptions
Using exceptions we can pinpoint what happened.
Imagine how hard will be without exceptions to pass as parameters more jni
methods/fields results ...
Cheers,
BogDan.
--
Best Regards,
Fanaskov Vitaly
Senior Software Engineer
The Qt Company
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
Hi,
În ziua de joi, 5 martie 2020, la 17:14:44 EET, Vitaly Fanaskov a scris:
> I think something like std::expected is a nice thing to have.
>
> There is some experimental implementation of std::expected:
> https://github.com/TartanLlama/expected.
>
That implementation is my favorite, I really like the map, map_error,
and_then, or_else additions ;-) .
[...]
>
> Regarding using exceptions, well, I would vote for this option, but I
> don't think that this is possible at all to convince people to use
> exceptions in this module.
>
A single Qt JNI call might fail in different places, e.g.:
auto str1 = QAndroidJniObject::callStaticObjectMethod("MyClass",
"fromNumber",
"(I)Ljava/lang/String;",
10);
1. check if there is any pending exceptions on current JNI Env
2. check if the method signature is okay
3. check if the method call throw any exceptions
Using exceptions we can pinpoint what happened.
Imagine how hard will be without exceptions to pass as parameters more jni
methods/fields results ...
Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
On Thursday, 5 March 2020 07:29:07 PST Bogdan Vatra via Development wrote: > În ziua de joi, 5 martie 2020, la 17:21:11 EET, Thiago Macieira a scris: > > On Thursday, 5 March 2020 07:14:44 PST Vitaly Fanaskov wrote: > > > I think something like std::expected is a nice thing to have. > > > > > > There is some experimental implementation of std::expected: > > > https://github.com/TartanLlama/expected. > > > > > > Another good example is Result > > > (https://doc.rust-lang.org/std/result/index.html) type from Rust. But > > > might look clumsy in C++, because there is neither pattern matching nor > > > operator? > > > (https://doc.rust-lang.org/std/result/index.html#the-question-mark-opera > > > to > > > r-> ) to handle this case gracefully. > > > > We have QSystemResult in QtCore already. This predates both std::expected > > and Result from Rust. > > > > One of my abandoned commits (see the I/O thread) was an update to it to > > make it better. > > Where is QSystemResult? I can't find it in dev branch ... Did you rename it? Ah, sorry, we only have QSystemError. QSystemResult is the class I added and abandoned in Idaa189413f404cffb1eafffd14cef83d45089eee. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
În ziua de joi, 5 martie 2020, la 17:21:11 EET, Thiago Macieira a scris: > On Thursday, 5 March 2020 07:14:44 PST Vitaly Fanaskov wrote: > > I think something like std::expected is a nice thing to have. > > > > There is some experimental implementation of std::expected: > > https://github.com/TartanLlama/expected. > > > > Another good example is Result > > (https://doc.rust-lang.org/std/result/index.html) type from Rust. But > > might look clumsy in C++, because there is neither pattern matching nor > > operator? > > (https://doc.rust-lang.org/std/result/index.html#the-question-mark-operato > > r-> ) to handle this case gracefully. > We have QSystemResult in QtCore already. This predates both std::expected > and Result from Rust. > > One of my abandoned commits (see the I/O thread) was an update to it to make > it better. Where is QSystemResult? I can't find it in dev branch ... Did you rename it? Cheers, BogDan. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
On Thursday, 5 March 2020 07:14:44 PST Vitaly Fanaskov wrote: > I think something like std::expected is a nice thing to have. > > There is some experimental implementation of std::expected: > https://github.com/TartanLlama/expected. > > Another good example is Result > (https://doc.rust-lang.org/std/result/index.html) type from Rust. But > might look clumsy in C++, because there is neither pattern matching nor > operator? > (https://doc.rust-lang.org/std/result/index.html#the-question-mark-operator-> > ) to handle this case gracefully. We have QSystemResult in QtCore already. This predates both std::expected and Result from Rust. One of my abandoned commits (see the I/O thread) was an update to it to make it better. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make Qt6 JNI API safer to use
I think something like std::expected is a nice thing to have. There is some experimental implementation of std::expected: https://github.com/TartanLlama/expected. Another good example is Result (https://doc.rust-lang.org/std/result/index.html) type from Rust. But might look clumsy in C++, because there is neither pattern matching nor operator? (https://doc.rust-lang.org/std/result/index.html#the-question-mark-operator-) to handle this case gracefully. Regarding using exceptions, well, I would vote for this option, but I don't think that this is possible at all to convince people to use exceptions in this module. On 3/5/20 1:12 PM, Bogdan Vatra via Development wrote: > Hi, > >I started to review and move androidextras to qtbase (qtbase/src/corelib/ > platform/android). Here we have a problem with our Qt JNI API. The problem is > that in Java exceptions are (ab)used everywhere. Even if we have a way to > check for exceptions after each call in Qt, it's not used (not even by us in > Qt code itself), mostly because it's a little unwieldy to use it. To fix this > issue I'd like to discuss with you a few options: > > 1 - add something similar to std::expected[0] or outcome[1] to Qt. We can't > use std::optional because it doesn't work for void function e.g. > std::optional callMethod(). std::expected allows our API users to > handle the errors without try/catch. I think std::expected will be useful in > many places not only for QtJNI e.g. QJsonDocument > QJsonDocument::fromJson(const QByteArray , QJsonParseError *error = > nullptr) or any other place where we pass the error result as an argument. > Of course we still need to enable exceptions as if we try to access the > returned value without checking its state first it will still throw an > exception if the value is not valid. > > 2 - use exceptions (at least for android?). This means if a JNI call fails it > will throw a C++ exception. IMHO this is by far the best, cleanest and easiest > solution. > > 3 - I'm open for better ideas which makes the coding safer and *easier*. > > Cheers, > BogDan. > > [0] https://wg21.link/P0323R9 sadly it's not in c++20 :( therefore we need to > either use an existing implementation or implement one in Qt. > [1] https://ned14.github.io/outcome/ > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Make Qt6 JNI API safer to use
Hi, I started to review and move androidextras to qtbase (qtbase/src/corelib/ platform/android). Here we have a problem with our Qt JNI API. The problem is that in Java exceptions are (ab)used everywhere. Even if we have a way to check for exceptions after each call in Qt, it's not used (not even by us in Qt code itself), mostly because it's a little unwieldy to use it. To fix this issue I'd like to discuss with you a few options: 1 - add something similar to std::expected[0] or outcome[1] to Qt. We can't use std::optional because it doesn't work for void function e.g. std::optional callMethod(). std::expected allows our API users to handle the errors without try/catch. I think std::expected will be useful in many places not only for QtJNI e.g. QJsonDocument QJsonDocument::fromJson(const QByteArray , QJsonParseError *error = nullptr) or any other place where we pass the error result as an argument. Of course we still need to enable exceptions as if we try to access the returned value without checking its state first it will still throw an exception if the value is not valid. 2 - use exceptions (at least for android?). This means if a JNI call fails it will throw a C++ exception. IMHO this is by far the best, cleanest and easiest solution. 3 - I'm open for better ideas which makes the coding safer and *easier*. Cheers, BogDan. [0] https://wg21.link/P0323R9 sadly it's not in c++20 :( therefore we need to either use an existing implementation or implement one in Qt. [1] https://ned14.github.io/outcome/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
