Closed Bug 347019 Opened 18 years ago Closed 17 years ago

Don't throw exception when no accessible for node in nsIAccessibleRetrieval::getAccessibleFor() and friends

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: surkov)

References

Details

(Keywords: access)

Attachments

(1 file)

It is very normal for a DOM node not to have an accessible associated with it.

Exceptions should be reserved for unexpected occurances or errors of some kind.

Therefore we should simply return null for the accessible, but NS_OK since there is no exception. We'll need to check all the callers to make sure they check the returned accessible and not the nsresult.
Similar to bug 337656.
Assignee: aaronleventhal → surkov.alexander
Attached patch patchSplinter Review
Attachment #253611 - Flags: review?(aaronleventhal)
Status: NEW → ASSIGNED
Comment on attachment 253611 [details] [diff] [review]
patch

David, enjoy your first code review :)
Attachment #253611 - Flags: review?(aaronleventhal) → review?(david.bolter)
Comment on attachment 253611 [details] [diff] [review]
patch

Looks good. One minor nit is that I see you are following the no {}'s for single line if's. I think for the accessible module we are including them.
Attachment #253611 - Flags: review?(david.bolter) → review+
(In reply to comment #4)
> (From update of attachment 253611 [details] [diff] [review])
> Looks good. One minor nit is that I see you are following the no {}'s for
> single line if's. I think for the accessible module we are including them.
> 

Though IIRC mozilla code styling guide doesn't define unuque way how to style single lines 'if'/'else' but for example, in toolkit, mano requires to remove them if they are. I don't like to have two or more code styling in mozilla code since it's awful to remember where should I use one style where should I use another one. Aaron, what's your point about code styling?
I won't require it either way at this point. We have both in the code and I think this is taking more time to talk about than it's worth. There are reasons for {} on single lines, but honestly I'm not interested in spending more time on the issue. Let's just check in the code. Try to be similar code in the file/method you are changing and we'll be fine.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Surkov, didn't we need to return NS_OK here?
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#1131

1130   if (!aAccessibleIn) {
1131     return NS_ERROR_FAILURE; // No accessible to init
1132   }
(In reply to comment #7)
> Surkov, didn't we need to return NS_OK here?
> http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#1131
> 
> 1130   if (!aAccessibleIn) {
> 1131     return NS_ERROR_FAILURE; // No accessible to init
> 1132   }
> 

let's move discussion to bug 385731
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: