I do not feel any conflicts with compiler diagnostic here. As the matter of
fact inspection does not check whether your program will compile
successfully. Having in mind your program is compilable it finds code
fragments that may violate semantic rules regardless their syntatic
validitiy. Having this in mind we agree that call to System.exit() changes
the flow of control in a matter other than other method calls do and this
should be processed in a different way.

Best regards,
Maxim Shafirov
IntelliJ Software, http://www.intellij.com/
"Develop with pleasure!"


----- Original Message -----
From: "Erb" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 14, 2002 6:26 PM
Subject: Re: [Eap-list] 611 local code analysis Bug


Just a note.  I believe Java compiler does not treat System.exit() as
special,
So if you had code like:

Object o;
if (b) {
    System.exit(1);
}
else {
    o = new Object();
}

int i = o.hashCode();


The compiler would warn about o possibly not being initialized.
Different case, but the idea is IDEA maybe should not treat System.exit
as special
either, beause it might go in conflict with the compiler.

Maxim Shafirov wrote:
> System.exit(...) problem fixed in build #612. Thank you Michael!
>
> Best regards,
> Maxim Shafirov
> IntelliJ Software, http://www.intellij.com/
> "Develop with pleasure!"
>
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, March 13, 2002 11:24 AM
> Subject: [Eap-list] 611 local code analysis Bug
>
>
> I see, that makes sense!
>
> But I found this problem:
>
>       if (cm == null)
>       {
>           System.exit(1);
>       }
>       String name = cm.getName();
>
> and code inspections warns that cm.getName() could throw NPE
> The same is possible if instead of System.exit there was a call
> to a method that throws Error, like SomeClass.throwAssertion()
>
> ----
> in the your sample o != null is really always true. If not you'll get
> java.lang.NullPointerException in the previous line. So if (o != null)
will
> never get control if o is null.
>
>
>>JDK1.3.1, NT4, build 611
>>
>>when running local code analysis I get various results
>>where the code checks against null, and IDEA says
>>"is always true" or "is always false" - which is not the case.
>>
>>sometimes, if the (xyz!=null) is in a finally-block,
>>and sometimes, it seems, if a method parameter is accessed
>>before the check against null, reproducable with this code:
>>
>>private void getRemaining(Object o)
>> {
>>      o.getClass();
>>      if (o != null)
>>      {
>>
>>      }
>>}
>
>
>
____________________________________________________________________________
> __
> Tagesgeld: 4% Guthabenzinsen bei t�glicher Verf�gbarkeit. Jetzt
informieren!
> http://diba.web.de/
>
>
> _______________________________________________
> Eap-list mailing list
> [EMAIL PROTECTED]
> http://www.intellij.com/mailman/listinfo/eap-list
>
>
> _______________________________________________
> Eap-list mailing list
> [EMAIL PROTECTED]
> http://www.intellij.com/mailman/listinfo/eap-list
>


--

Erb

==============================================================
"The only time I like in the morning is afternoon."
     - Russell D. Cooper

"If you do everything, then you're all done."
     - Melissa F. Cooper

"Most of you are familiar with the virtues of a programmer.
There are three, of course: laziness, impatience, and hubris."
     - Larry Wall
==============================================================


_______________________________________________
Eap-list mailing list
[EMAIL PROTECTED]
http://www.intellij.com/mailman/listinfo/eap-list


_______________________________________________
Eap-list mailing list
[EMAIL PROTECTED]
http://www.intellij.com/mailman/listinfo/eap-list

Reply via email to