再问一个今天的面试题 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

再问一个今天的面试题

再问一个今天的面试题# Java - 爪哇娇娃

s*i2010-02-19 08:02

1 楼

关于java reflection的
Suppose class ClassName immplements runnable interface. Write a function
which returns a thread that attached with this class, taking the class name
string as argument.
我这么写的：
public Thread myFunction (String s) {
Thread t=null;

try {
Object o = Class.forName(s).newInstance();
t = new Thread((Runnable)o);
}
catch(Exception e ){

c*t2010-02-19 08:02

2 楼

Catching Throwable is better though. Sometimes class loading
can get you wierd Throwable such as class version error etc.

name

【在 s*****i 的大作中提到】

: 关于java reflection的
: Suppose class ClassName immplements runnable interface. Write a function
: which returns a thread that attached with this class, taking the class name
: string as argument.
: 我这么写的：
: public Thread myFunction (String s) {
: Thread t=null;
:
: try {
: Object o = Class.forName(s).newInstance();

l*s2010-02-19 08:02

3 楼

agree.
Runnable的cast好象也没必要
return t;应该放进try/catch block里，或finally里
面试的人大概也希望你把ClassNotFoundException先catch住，然后再catch Throwable
本人新手，只知道和做过一些基本的Java，也准备找工作了，希望大家多分享一些面试
题和经验。谢谢！

【在 c*****t 的大作中提到】

: Catching Throwable is better though. Sometimes class loading
: can get you wierd Throwable such as class version error etc.
:
: name

g*g2010-02-19 08:02

4 楼

I don't see why one wants to catch an Error. So catch Exception
sounds right for me.

【在 c*****t 的大作中提到】

: Catching Throwable is better though. Sometimes class loading
: can get you wierd Throwable such as class version error etc.
:
: name

s*i2010-02-19 08:02

5 楼

不要runnable cast怎么能编译

Throwable

【在 l**s 的大作中提到】

: agree.
: Runnable的cast好象也没必要
: return t;应该放进try/catch block里，或finally里
: 面试的人大概也希望你把ClassNotFoundException先catch住，然后再catch Throwable
: 本人新手，只知道和做过一些基本的Java，也准备找工作了，希望大家多分享一些面试
: 题和经验。谢谢！

l*s2010-02-19 08:02

6 楼

you are right,应该cast. 我看走眼了。

m*t2010-02-19 08:02

7 楼

+1. If an Error is caught here, there probably isn't much point
carrying on anyway.

【在 g*****g 的大作中提到】

: I don't see why one wants to catch an Error. So catch Exception
: sounds right for me.

c*t2010-02-19 08:02

8 楼

Not necessarily. The point is to be able to ** gracefully **
handle errors.
If you are on the server, maybe there isn't a point since the web
server would report it anyways.
On the client though, you would want to report such error gracefully.
For example, you could say "unable to load the plugin" rather than
some mysterious exception backtraces. Some other times, you may
not want to crash your whole application (Office for instance) just
because a plugin crashed.

【在 m******t 的大作中提到】

:
: +1. If an Error is caught here, there probably isn't much point
: carrying on anyway.

m*t2010-02-19 08:02

9 楼

You are of course correct in principle, but remember we are talking about
errors not common exceptions. I can't think of any particular Error subclass
that if thrown is even worth recovering from. Typically if an Error is
thrown, that means at least the thread or even the whole vm is done for.

【在 c*****t 的大作中提到】

: Not necessarily. The point is to be able to ** gracefully **
: handle errors.
: If you are on the server, maybe there isn't a point since the web
: server would report it anyways.
: On the client though, you would want to report such error gracefully.
: For example, you could say "unable to load the plugin" rather than
: some mysterious exception backtraces. Some other times, you may
: not want to crash your whole application (Office for instance) just
: because a plugin crashed.

c*t2010-02-19 08:02

10 楼

There are in fact two on top of my head:
1. UnsupportedClassVersionError. For instance, you were trying to load 1.5
classes from 1.4 JVM or 1.6 class from 1.5 JVM. This is the most common.
2. ExceptionInInitializerError (the class initializer throws an exception
that caused the class loading to fail). Again, a poorly written plugin
(with false assumption in class initialization code and forgot to catch
RuntimeException) could easily terminate the whole program.
There are certainly

【在 m******t 的大作中提到】

: You are of course correct in principle, but remember we are talking about
: errors not common exceptions. I can't think of any particular Error subclass
: that if thrown is even worth recovering from. Typically if an Error is
: thrown, that means at least the thread or even the whole vm is done for.

m*t2010-02-19 08:02

11 楼

Now it looks to me like our difference isn't really in picking out non-
recoverable errors, but in what we would consider "recoverable", 8-), which
I understand can be fairly subjective.
If I'm starting an app server, and a class can't be loaded or initialized, I
would simply panic and refuse to open the gate and let customers in. I
would have to figure out what's wrong with that class, fix it, and try again.

5
common.

【在 c*****t 的大作中提到】

: There are in fact two on top of my head:
: 1. UnsupportedClassVersionError. For instance, you were trying to load 1.5
: classes from 1.4 JVM or 1.6 class from 1.5 JVM. This is the most common.
: 2. ExceptionInInitializerError (the class initializer throws an exception
: that caused the class loading to fail). Again, a poorly written plugin
: (with false assumption in class initialization code and forgot to catch
: RuntimeException) could easily terminate the whole program.
: There are certainly

c*t2010-02-19 08:02

12 楼

Like I said, on the server, it may not matter since you have the full
control and it really doesn't matter. In fact, it is better because
you want problems show up as early as possible before putting it on
the production server. Normally user shouldn't be exposed to these
kind of stuff anyways.
However, on the client side, you have no control over what user might
do and which JVMs they run. Thus, being able to ** gracefully ** report
errors is a critical user interface.
Particularly for a win

【在 m******t 的大作中提到】

: Now it looks to me like our difference isn't really in picking out non-
: recoverable errors, but in what we would consider "recoverable", 8-), which
: I understand can be fairly subjective.
: If I'm starting an app server, and a class can't be loaded or initialized, I
: would simply panic and refuse to open the gate and let customers in. I
: would have to figure out what's wrong with that class, fix it, and try again.
:
: 5
: common.

g*g2010-02-19 08:02

13 楼

Not sure what you are doing on client side. If you have
pluggable infrastructure that tries to load unknown code,
then what you said makes sense.
In most other cases, you want it to fail quickly.

【在 c*****t 的大作中提到】

: Like I said, on the server, it may not matter since you have the full
: control and it really doesn't matter. In fact, it is better because
: you want problems show up as early as possible before putting it on
: the production server. Normally user shouldn't be exposed to these
: kind of stuff anyways.
: However, on the client side, you have no control over what user might
: do and which JVMs they run. Thus, being able to ** gracefully ** report
: errors is a critical user interface.
: Particularly for a win

m*t2010-02-19 08:02

14 楼

Fair enough. Different contexts I guess.

【在 c*****t 的大作中提到】

s*e2010-02-19 08:02

15 楼

if you ever grab a scarce resource in your construtor (I am not saying you
shoud do that, but there might be some scenario you want to do that. )
catching throwable to release it does make sense.

g*g2010-02-19 08:02

16 楼

I think that's something want to do in finally,
unless your finally may throw an Error and you want
to do it there.

【在 s******e 的大作中提到】

: if you ever grab a scarce resource in your construtor (I am not saying you
: shoud do that, but there might be some scenario you want to do that. )
: catching throwable to release it does make sense.

s*e2010-02-19 08:02

17 楼

finally will run even without an exception. You do not want to release your
resource if everything goes smoothly.
flagging in exception handling block to inform finally block is another way
to do it, but essentailly it is not that different from handling in
exception handling block.

m*t2010-02-19 08:02

18 楼

your
If the resource is "scarce", it would make sense to release
it.

【在 s******e 的大作中提到】

: finally will run even without an exception. You do not want to release your
: resource if everything goes smoothly.
: flagging in exception handling block to inform finally block is another way
: to do it, but essentailly it is not that different from handling in
: exception handling block.

s*e2010-02-19 08:02

19 楼

not neccessary.
For example, I want to support many types of DBs, so I define some calss to
manage the connection pool for each DB type. Depending on your
configuaration or some run time parameter, I will load the class on the fly,
when I load the class, I will create the connection pool for this type of
DB. If it goes smoothly, I will be happy to use it, but if something bad
happen, I want to return the connection to DB so I won't have connection
leak.

r*l2010-02-19 08:02

20 楼

这个题挺无聊的。

name

【在 s*****i 的大作中提到】

r*l2010-02-19 08:02

21 楼

In theory and in most cases, Magicfat is right about
releasing resources.

to
fly,

【在 s******e 的大作中提到】

: not neccessary.
: For example, I want to support many types of DBs, so I define some calss to
: manage the connection pool for each DB type. Depending on your
: configuaration or some run time parameter, I will load the class on the fly,
: when I load the class, I will create the connection pool for this type of
: DB. If it goes smoothly, I will be happy to use it, but if something bad
: happen, I want to return the connection to DB so I won't have connection
: leak.