Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #16082 > unrolled thread

throw null investigation

Back to article view | Back to comp.lang.java.programmer

Contents

  throw null investigation bob smith <bob@coolfone.comze.com> - 2012-07-18 10:10 -0700
    Re: throw null investigation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-18 12:39 -0700
      Re: throw null investigation markspace <-@.> - 2012-07-18 13:35 -0700
        Re: throw null investigation Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-18 23:33 +0200
          Re: throw null investigation markspace <-@.> - 2012-07-18 14:43 -0700
            Re: throw null investigation Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-19 00:06 +0200
              Re: throw null investigation markspace <-@.> - 2012-07-18 15:55 -0700
                Re: throw null investigation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-18 16:00 -0700
                  Re: throw null investigation Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-07-18 16:16 -0700
    Re: throw null investigation Roedy Green <see_website@mindprod.com.invalid> - 2012-07-18 17:09 -0700

#16082 — throw null investigation

Is it common practice to throw a null exception when writing JNI code?

I'm seeing an exception that is simply a null rather than an object, and I'm wondering if it's because it's easier to do that in JNI.

[toc] | [next] | [standalone]

#16083

On 7/18/12 10:10 AM, bob smith wrote:
> Is it common practice to throw a null exception when writing JNI code?
>
> I'm seeing an exception that is simply a null rather than an object, and I'm wondering if it's because it's easier to do that in JNI.
>
 From what I can tell, that shouldn't ever happen. I'm not sure in JNI, 
but I know in Java if you throw a "null", it will instead throw a 
NullPointerException, so anyone catching that Throwable will not see a 
"null" value, but instead a NullPointerException instance.

[toc] | [prev] | [next] | [standalone]

#16084

On 7/18/2012 12:39 PM, Daniel Pitts wrote:
> On 7/18/12 10:10 AM, bob smith wrote:
>> Is it common practice to throw a null exception when writing JNI code?
>>
>> I'm seeing an exception that is simply a null rather than an object,
>> and I'm wondering if it's because it's easier to do that in JNI.
>>
>  From what I can tell, that shouldn't ever happen. I'm not sure in JNI,
> but I know in Java if you throw a "null", it will instead throw a
> NullPointerException, so anyone catching that Throwable will not see a
> "null" value, but instead a NullPointerException instance.
>


In Java, yes.  But in JNI, in C, I'd expect it is possible to literally 
throw an empty or null pointer.

I'd also expect that any code that did that was sub-par, and not worth 
using or debugging.

I'm mildly interested in what the OP is using, mostly so I can avoid it. 
  However if he can supply some details (*what* are you using, Bob?) I'd 
consider taking a loot at it.  The actually question he asks: "Is it 
common practice," I don't really know or care.  It seems bad practice, 
but I've never dealt with JNI code, so what do I know?

[toc] | [prev] | [next] | [standalone]

#16088

On 18/07/2012 22:35, markspace allegedly wrote:
> On 7/18/2012 12:39 PM, Daniel Pitts wrote:
>> On 7/18/12 10:10 AM, bob smith wrote:
>>> Is it common practice to throw a null exception when writing JNI code?
>>>
>>> I'm seeing an exception that is simply a null rather than an object,
>>> and I'm wondering if it's because it's easier to do that in JNI.
>>>
>>  From what I can tell, that shouldn't ever happen. I'm not sure in JNI,
>> but I know in Java if you throw a "null", it will instead throw a
>> NullPointerException, so anyone catching that Throwable will not see a
>> "null" value, but instead a NullPointerException instance.
>>
> 
> 
> In Java, yes.  But in JNI, in C, I'd expect it is possible to literally
> throw an empty or null pointer.
> 
> I'd also expect that any code that did that was sub-par, and not worth
> using or debugging.
> 
> I'm mildly interested in what the OP is using, mostly so I can avoid it.
>  However if he can supply some details (*what* are you using, Bob?) I'd
> consider taking a loot at it.  The actually question he asks: "Is it
> common practice," I don't really know or care.  It seems bad practice,
> but I've never dealt with JNI code, so what do I know?
> 

But if the JNI code actually wanted to throw an NPE, and teh Jav wraps a
null into an NPE, wouldn't it actually be more efficient if the JNI code
"threw" a null?

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#16090

On 7/18/2012 2:33 PM, Daniele Futtorovic wrote:

> But if the JNI code actually wanted to throw an NPE, and teh Jav wraps a
> null into an NPE, wouldn't it actually be more efficient if the JNI code
> "threw" a null?


That's what I'm saying.  I think perhaps Java does NOT wrap a null 
exception thrown by JNI code.  Java wraps a null value when you throw it 
from Java, but JNI tends to have a lot of holes, especially if you are 
dealing with "signed" or "trusted" code.  There's ways to get around the 
checks Java does of JNI code in the interest of speed, and if you don't 
check, then you don't get protection.

[toc] | [prev] | [next] | [standalone]

#16092

On 18/07/2012 23:43, markspace allegedly wrote:
> On 7/18/2012 2:33 PM, Daniele Futtorovic wrote:
> 
>> But if the JNI code actually wanted to throw an NPE, and teh Jav wraps a
>> null into an NPE, wouldn't it actually be more efficient if the JNI code
>> "threw" a null?
> 
> 
> That's what I'm saying.  I think perhaps Java does NOT wrap a null
> exception thrown by JNI code.  Java wraps a null value when you throw it
> from Java, but JNI tends to have a lot of holes, especially if you are
> dealing with "signed" or "trusted" code.  There's ways to get around the
> checks Java does of JNI code in the interest of speed, and if you don't
> check, then you don't get protection.

But if what you say is correct, and Java does /not/ systematically wrap
nulls "thrown" from JNI (assuming it's possible), then it would be
technically possible to catch a null Exception in the Java runtime,
wouldn't it?

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#16095

On 7/18/2012 3:06 PM, Daniele Futtorovic wrote:
>
> But if what you say is correct, and Java does /not/ systematically wrap
> nulls "thrown" from JNI (assuming it's possible), then it would be
> technically possible to catch a null Exception in the Java runtime,
> wouldn't it?


I want to emphasize there than I'm speculating and extrapolating from 
barely remembered blogs.  It's something for the OP to consider, but 
he's going to have to decide if I'm talking rubbish or not.

Executive summary: I dunno.

[toc] | [prev] | [next] | [standalone]

#16096

On 7/18/12 3:55 PM, markspace wrote:
> On 7/18/2012 3:06 PM, Daniele Futtorovic wrote:
>>
>> But if what you say is correct, and Java does /not/ systematically wrap
>> nulls "thrown" from JNI (assuming it's possible), then it would be
>> technically possible to catch a null Exception in the Java runtime,
>> wouldn't it?
>
>
> I want to emphasize there than I'm speculating and extrapolating from
> barely remembered blogs.  It's something for the OP to consider, but
> he's going to have to decide if I'm talking rubbish or not.
>
> Executive summary: I dunno.
>
>
>
Lets check the JLS...

[toc] | [prev] | [next] | [standalone]

#16097

On 7/18/12 4:00 PM, Daniel Pitts wrote:
> On 7/18/12 3:55 PM, markspace wrote:
>> On 7/18/2012 3:06 PM, Daniele Futtorovic wrote:
>>>
>>> But if what you say is correct, and Java does /not/ systematically wrap
>>> nulls "thrown" from JNI (assuming it's possible), then it would be
>>> technically possible to catch a null Exception in the Java runtime,
>>> wouldn't it?
>>
>>
>> I want to emphasize there than I'm speculating and extrapolating from
>> barely remembered blogs.  It's something for the OP to consider, but
>> he's going to have to decide if I'm talking rubbish or not.
>>
>> Executive summary: I dunno.
>>
>>
>>
> Lets check the JLS...
>
Actually, the JLS doesn't seem to handle this, but the JNI spec does:

<http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp17593>
> The JNI does not check for programming errors such as passing in NULL pointers or illegal argument types.
[snip]
> The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash.

It seems to me then, if the JNI code is passing NULL to "Throw" or 
"ThrowNew", it is "undefined" behavior.

[toc] | [prev] | [next] | [standalone]

#16100

On Wed, 18 Jul 2012 10:10:02 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>Is it common practice to throw a null exception when writing JNI code?

It is an unusual thing to do. It has the same effect of throwing a
NullPointerException.  Sun had to figure out what to do if the
reference thrown were null.  That seemed as reasonable a way of
handling it as any.  However, in my view, it is really a mistake. You
should not be writing code that looks like a mistake.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function. 
 ~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)
http://www.youtube.com/watch?v=F-QA2rkpBSY

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web