Issue 3255: Use of names in defined exceptions                                                                                                                                                                      (rad-ftf)
Source: 2AB (Mr. Bob Burt, bburt@2ab.com)
Nature: Uncategorized Issue
Severity: 
Summary: Some of the exceptions defined could use names that are less like to
conflict with standard language objects and thus would not have to be fully
qualified.  For example, InternalError conflicts with
java.lang.InternalError.  Perhaps RadInternalError might be nicer.
ComponentError might be another candidate for RadComponentError.

Resolution: resolved
Revised Text: Issues 3255 and Issue 3178D have been linked.
Issue 3255 Summary –
Some of the exceptions defined could use names that are less like to conflict with
standard language objects and thus would not have to be fully qualified. For
example, InternalError conflicts with java.lang.InternalError. Perhaps
RadInternalError might be nicer. ComponentError might be another
candidate for RadComponentError.
Comment: The IDL looked like this at one time. This is the source of issue 3178D
where the text uses these names. For some reason the "Rad" prefix was
removed in the final editing.
Issue 3178D Summary –
[Errata] Fatal rather than RadFatal, according to the IDL references "If the
ComponentError is RadFatal, the AccessDecision
object must determine if it can continue to process without the component."
[Errata] InternalError rathan RadInternalError, according to
the IDL. references "If it cannot, it must throw a RadInternalError."
[Errata] Fatal rather than RadFatal, according to the IDL references "with
RadFatal."
All three of these comments (for 3178D) are related to text found under
ComponentError in section 2.2.5 Exceptions, on page 2-10 of the draft
Adopted Specification.
Resolution (for both issues):
Change the following exception names and all references to them in the text:
InternalError to RadInternalError ComponentError to
RadComponentError Leave these specific names (RadInternalError and
RadComponentError) the same in the sentence referenced in Issue 3178D as they are now correct. Change RadFatal to Fatal in the section referenced by
issue 3178D and anywhere else it appears incorrectly (this is an enumerated
value, not an Exception).
Actions taken:
January 26, 2000: received issue
January 9, 2001: closed issue
Discussion: 

End of Annotations:=====
X-Sender: bburt@mindspring.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 26 Jan 2000 14:30:50 -0600
To: <rad-ftf@omg.org>
From: Bob Burt <bburt@2ab.com>
Subject: RAD FTF comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-UIDL: N3f!!Q/;e9i6V!!BQ@e9

A couple of minor issues for the RAD FTF:


Issue 3:

Some of the exceptions defined could use names that are less like to
conflict with standard language objects and thus would not have to be
fully
qualified.  For example, InternalError conflicts with
java.lang.InternalError.  Perhaps RadInternalError might be nicer.
ComponentError might be another candidate for RadComponentError.

> >> Issue 3:
> >>
> >> Some of the exceptions defined could use names that are less like
> to
> >> conflict with standard language objects and thus would not have
> to be fully
> >> qualified.  For example, InternalError conflicts with
> >> java.lang.InternalError.  Perhaps RadInternalError might be
> nicer.
> >> ComponentError might be another candidate for RadComponentError.
> >
> >What is the difference between RadComponentError and
> >DfResourceAccessDecision.InternalError? Less typing? If so, we can
> either
> >resolve this issue by saying that amount of typing with nowadays
> IDEs is
> not an
> >issue. Or, we can change the module name to DfRAD. Then all the
> classes and
> >exceptions could be cvalified with prefix "DfRAD.", without
> unnatural
> steps on
> >our site, by typing DfRAD.InternalError and so on.
> >
> Actually typing is not really the issue, the issue is that when
> writing an
> implemenation, it is almost never necessary to use a fully qualified
> name
> and all of a sudden here comes a name that conflicts. To me its just
> easier
> to just pick names that minimize conflicts (you can never guarantee
> no
> conflicts).

My experience shows that no matter how much you try to name classes so
that
names are globally unique, you run into name conflicts from time to
time. For
example there are java.lang.Object and org.omg.CORBA.Object.

Also, this issue should be a wish item, since it does not identify a
problem
(all languages nowadays have name scoping mechanisms) but asks for
convenience
for Java programmers.

> 
> >>

>>> >> Issue 3:
>>
>>My experience shows that no matter how much you try to name classes
so that
>>names are globally unique, you run into name conflicts from time to
time.
For
>>example there are java.lang.Object and org.omg.CORBA.Object.
>>

Agree.


>>Also, this issue should be a wish item, since it does not identify a
problem
>>(all languages nowadays have name scoping mechanisms) but asks for
>convenience for Java programmers.
>>

I agree.