ClError should print human-readable message even for Debug output.

[KarelPeeters]

Currently, when experimenting with code and an unwrap happens, I get output like this:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ClError(-51)'

And then I have to look through the possible error codes myself, which is not very convenient.

It's already possible to get a human-readable name for the error by using the Display trait, but that's not very useful since existing utilities (like unwrap) mostly use Debug.

[kenba]

I disagree. I made a deliberate decision to have different output for the Display and Debug traits.

Debug currently derives from the standard Debug trait. It's simple and always outputs the correct OpenCL error number which, whether you like it or not, is "human readable".

Display uses a match statement to all the known OpenCL error numbers. However, it will not have text for new OpenCL features or extensions when they are added. In which case it will output "UNKNOWN_ERROR", which is of no use to anyone.

As you are most likely aware, it's considered bad practice to use unwrap. So I'm not comfortable changing the library to support it.

I propose that you put the code that may raise an error in a function that returns an opencl3::Result. You can then use the ? operator in the function and use whatever you want to display an Error Result.

[KarelPeeters]

I agree that getting UNKNOWN_ERROR back is undesirable, I've had a few -999 errors already. Maybe always including both the error code and the readable string in the output would make sense?

The problem with the ? operator is that is loses all context for where the error actually happened, which is a pain during prototyping and development. Additionally many of the errors returned by this API are caused by invalid usage (eg wrong kernel parameter types, invalid argument combinations or values, ...) where unwrap really is the proper solution.

I don't really see any downside to making the debug output more readable for developers, that's the point of it!

[kenba]

I'm sorry @KarelPeeters but I'm not willing to change debug output because of the "UNKNOWN_ERROR" issue with new features and extensions.

Another way you could get an error name during prototyping and development is simply by calling unwrap_or_else instead of unwrap, e.g.:

    let value = device.half_fp_config().unwrap_or_else(|e| {
        println!("OpenCL error, {}", e);
        0
    });

This way you may also get both the name and the error code by adding debug in the call to println!.
Either way, it leaves error formatting to whatever the user wants, so it is my preferred solution.