vulkano: [Feedback wanted] Should Vulkano panic on validation errors instead?

Vulkano returns errors from a lot of functions, indicating what are essentially validation errors: something wasn’t correct about the arguments. AutoCommandBufferBuilder in particular has a huge list of error types, for all of the different operations it can perform.

Thinking about it, though, it seems to me that the user would rarely, if ever, actually respond to any of these errors. If draw fails because you provided improper arguments, what would you actually do in this case? You did something dumb, that’s not something your application is meant to recover from. It’s going to happen every time you run your program. You’re supposed to treat it as a bug and fix it.

So I think it’s probably better to respond to validation errors with a panic instead of returning a useless error to the user. The user would then not be led to believe that it’s an error they actually should handle. Let’s face it, you don’t. You put .unwrap() everywhere and call it a day. Even Vulkano’s examples do. Removing all those superfluous error types would also slim down Vulkano’s API a fair bit.

Keep in mind, this is specifically about validation errors: errors that can be detected before any call to Vulkan is actually made, determined purely by the arguments of a function. Errors resulting from a Vulkan call after the fact would remain in place, of course.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 17 (16 by maintainers)

Most upvoted comments

Ok, I won’t pursue this any further then, but I can leave it open in case people have new input.

Rua on Apr 22, 2021

Also, I think including the specific Vulkan VUID in all validation errors in some form is a must too.

Rua on Apr 22, 2021

How about keeping the individual errors as they are, but grouping all errors that a function can return under an enum like this?

enum VulkanoError<R, V> {
    Runtime(R),
    Validation(V),
}

This is parameterised, so a function would specify concrete types for R and V in its signature. Then users are still free to respond to any error they wish, but they can also easily filter out validation errors. The enum could also be given methods to make it easier for the user to panic on validation errors (the behaviour I’d like in my project), but I’m not sure yet what the best design for that would be. Ideas welcome.

Rua on Apr 22, 2021

I currently don’t have much time to elaborate on this, but I believe the Rust way of doing this is how it’s currently done. Mostly. There are some places where error handling must be re-thought because it assumes that the user unwraps anyways and leaves objects in error states. However, in most places I believe things are fine the way they are.

Panics should only happen when something happens that should not have happened and is completely unexpected. Wrong usage by the user is definitely not a case where a panic should normally occour. Of course every rule has it’s exceptions.

I would also vote against a unified error type as it usually makes actual error handling much harder while simplifying error reporting. This is at least my experience.

faulesocke on Apr 21, 2021

Hahaha yeah. I had my thoughts on the question here:

https://github.com/vulkano-rs/vulkano/commit/65254ed10c81694e45555e6044851b718ae200c0

I personally would favor an unified error type that prints the Valid Usage ID (VUID) of the validation error and debug statement. Panics, while safe, are considered rude by some.

Fits nicely with the try operator.

gurchetansingh on Apr 13, 2021