Hi!
I noticed that
try { System.getSecurityManager().checkXXX(); }
catch(NullPointerException e) { }
code is used throw classpath. What is a reason for that?
I wrote a simple test case like:
class x
{
/*
x() throws SecurityException {
try {
System.getSecurityManager().checkCreateClassL
On Fri, 18 Aug 2000 [EMAIL PROTECTED] wrote:
> I wrote a simple test case like:
> class x
> {
> /*
> x() throws SecurityException {
> try {
>System.getSecurityManager().checkCreateClassLoader();
> } catch(NullPointerException e) {
> }
> */
> x() throws SecurityException {
> Security
Patrick LAM wrote:
>
> Catching exceptions is extremely slow, as is anything in general which has
> to do with exceptions. I would say that the second idiom should always be
> favoured.
It depends - suppose catching an exception is 100 times slower than
doing a comparision to null. And then supp
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes:
>> Catching exceptions is extremely slow, as is anything in general
>> which has to do with exceptions. I would say that the second idiom
>> should always be favoured.
Stuart> It depends - suppose catching an exception is 100 times slo
Hi,
I think this is a very interesting subject. So far two solutions have
been proposed:
(a) if (sm != null) { sm.XXX(); }
(b) try { sm.XXX(); } catch (NullPointerException e){}
I'd like to propose a third solution. It requires more programming and
results in a larger binary, but on a JIT compi
Hi all!
Two points:
[1] You shouldn't explicitely test for "null" pointers, unless a null
pointer would normally be expected.
If we can assume that "sm" shouldn't be null in a bug free
program/library, then
try { sm.XXX(); } catch (NullPointerException e){}
is the right thing to do, as in a
Hi Etienne,
by default a JVM doesn't have a security manager. However, if we're
executing applets in a web browser the browser would install a security
manager to provide the "sandbox" security model. I agree with your
points. I find the idea of exceptions for optimisation an interesting
conc
Hi Ian.
Ian Rogers wrote:
> by default a JVM doesn't have a security manager. However, if we're
> executing applets in a web browser the browser would install a security
> manager to provide the "sandbox" security model.
I have not looked in details at the code, but do you really need to do
the
Hi Etienne,
> I have not looked in details at the code, but do you really need to do
> the test on every invocation of this specific method? Can't the test
> for security manager be done once and for all earlier? Then you can use
> inheritance/delegation (or other standard design patterns) to d
Ian Rogers wrote:
> > My comments on exceptions are NOT VM specific. Exceptions should be
> > "exceptional". From a VM designer point of view, the last thing to
> > optimize (in priority) is exceptions.
>
> I don't know. Saying exceptions are exceptional is one way of viewing
> there use. An al
Hi Etienne/All,
I feel as though this conversation has strayed away from what I wanted
to discuss. That was design patterns for dealing with null. I propose
there are 3 alternative solutions:
1) if (sm != null){sm.XXX();}
2) try {sm.XXX();}catch (NullPointerException e){}
3) initialise sm to a d
Ian Rogers wrote:
> 3) initialise sm to a default_sm object
This is probably the best alternative, but you must be careful in the
implementation of System.getSecurityManager(). This method should
return null when your "default" object is in place. (Otherwise, it
wouldn't conform to the API spec
Hi Etienne,
> From: Etienne M. Gagnon [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, August 19, 2000 4:04 PM
> Subject: Re: Why catch (NullPointerException e)?
> > > Exceptions should be "exceptional". From a VM
> > > designer point of view, the last thi
you wrote:
> I agree, however, the explicit null check will slow down the execution
> speed of applets.
Why? In case of a JIT or compiled Java for applets "if (sm != null)" will be branch
predicted and cause no harm at all. Moreover, AFAIK try/catch in general produce more
code and eve
Hi Igor,
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 22, 2000 9:02 AM
> Subject: Re: Why catch (NullPointerException e)?
>
> Ian wrote:
> > I agree, however, the explicit null check will slow
> > down the execution speed of appl
> "Etienne" == Etienne M Gagnon <[EMAIL PROTECTED]> writes:
Etienne> The general rule for exception is: An exception denotes an
Etienne> "exceptional" situation (no surprize!), and thus should not
Etienne> be used on the normal execution path of a program/library.
I first heard this statemen
Hi, Michal!
You wrote:
> Hi Igor,
>
> > Ian wrote:
> > > I agree, however, the explicit null check will slow
> > > down the execution speed of applets.
> >
> > Why? In case of a JIT or compiled Java for applets "if (sm !=
> > null)" will be branch predicted and cause no harm at all.
>
> Ok, I agree that cache misses with this policy is not that
> important although `if (sm != null)' produces less code which
> means shorter load time.
Well, you mileage may vary. In our VM, the load time hasn't been an issue
for any of the benchmarks we looked at. Our VM has two JIT compilers
Hi Igor,
> you wrote:
> > I agree, however, the explicit null check will slow down the execution
> > speed of applets.
>
> Why? In case of a JIT or compiled Java for applets "if (sm != null)" will be branch
>predicted and cause no harm at all. Moreover, AFAIK try/catch in general produce
19 matches
Mail list logo
