[patch] BLocale: B_ERROR gets returned from methods in the BLocale class ambiguously

[jscipione]

The problem that this enhancement ticket addresses is that B_ERROR gets returned from methods in the BLocale class in more than one instance so is ambiguous.

The solution I came up with is to change the status returned from B_ERROR to B_WOULD_BLOCK in the case that locking fails. The provides for B_ERROR to be returned only in the case that some ICU error happened. This way if you get a B_ERROR you know that it comes from ICU and not possibly because locking failed. Some investigation is still needed to figure out which ICU error caused B_ERROR to be returned.

[jscipione]

Updates B_ERROR status to B_WOULD_BLOCK if locking fails in BLocale classes

[jscipione]

Instead of returning B_WOULD_BLOCK how about B_NOT_ALLOWED? That is the error code that is returned by methods in the BClipboard class if you try to read or write to a BClipboard object that is not locked.

[pulkomandy]

I'd rather use B_BAD_DATA when the error comes from ICU side, as this likely means wrong input to it, and keep B_ERROR, for lack of a better one, if the locking fails (for lack of proper error handling in BAutolock)

what about that ?

[jscipione]

Why not use both B_NOT_ALLOWED and B_BAD_DATA and then save B_ERROR for something else?

[pulkomandy]

Well, the error with the locking is not that you're not allowed to do somethig. It's that there's major failure in the locale kit code somewhere (and should never happen anyway). So we can just return B_ERROR in that case, as it's not going to happen that often. B_NOT_ALLOWED is not fitting, it would give the user a message like "permission denied", which isn't the problem here.

[jscipione]

Ok, sounds reasonable to me.

[axeld]

As I told you earlier already, B_BAD_DATA is not what you are looking for, B_BAD_VALUE is. The former is when you pass corrupted data to a method (like when unarchiving a message), the latter is used when the arguments are invalid which is what happens there, right?

[jscipione]

Replying to axeld:

As I told you earlier already, B_BAD_DATA is not what you are looking for, B_BAD_VALUE is. The former is when you pass corrupted data to a method (like when unarchiving a message), the latter is used when the arguments are invalid which is what happens there, right?

Sounds good to me.

[jscipione]

Let's just leave this one as is.