Opened 11 years ago

Closed 10 years ago

#7901 closed enhancement (no change required)

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

Reported by: jscipione Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Kits/Locale Kit Version: R1/Development
Keywords: Cc: pulkomandy@…
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (1)

Locale_status_code_1.diff (4.0 KB ) - added by jscipione 11 years ago.
Updates B_ERROR status to B_WOULD_BLOCK if locking fails in BLocale classes

Download all attachments as: .zip

Change History (9)

by jscipione, 11 years ago

Attachment: Locale_status_code_1.diff added

Updates B_ERROR status to B_WOULD_BLOCK if locking fails in BLocale classes

comment:1 by jscipione, 11 years ago

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.

comment:2 by pulkomandy, 11 years ago

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 ?

comment:3 by jscipione, 11 years ago

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

comment:4 by pulkomandy, 11 years ago

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.

comment:5 by jscipione, 11 years ago

Ok, sounds reasonable to me.

comment:6 by axeld, 11 years ago

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?

in reply to:  6 comment:7 by jscipione, 11 years ago

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.

comment:8 by jscipione, 10 years ago

Resolution: no change required
Status: newclosed

Let's just leave this one as is.

Note: See TracTickets for help on using tickets.