error-handling

[Wolfram Rittmeyer <w....@proplant.de>]

Hi Jordi,

because of the reported WIN98-bug (14618) which occured in Help.java I just
diffed this file with version 1.6. Thereby I found something which I guess
is a result of your recent separation of tasks.

Up to version 1.7 a user got notified if an error occured during the
load-process of the help. Yet you took out this fragment because it would
cause a GUI-call which should not be made from a core-class (at least I
guess that's the reason).

I think this behavious is correct since I strongly support a separation of
gui and core-functionality. Yet shouldn't there be some kind of
notification? Maybe a thrown exception which the gui-part would be
responsible for to catch it? After all that's what you would expect from a
client-class, if it cannot fulfill the requested service, isn't it? Of
course this would mean quite some work on the gui-side.

I haven't searched around wether other core-classes have similar "issues".
If so, I would recommend a enhancement-request so that these issues do not
get lost over time. Do you (or anyone else) agree?

Though I guess right now there are some more urgent things to do...

Greetings,

Wolfram


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: error-handling

[Mike Stover <ms...@apache.org>]

I would suggest that line 185 in ActionRouter ought to have it's own try-catch.  
Probably around that entire while clause.  It is a somewhat frequent occurrence 
that loading classes into memory cause problems.  It would be nice to just skip 
those classes (log the problem), but continue with the rest.

In Help.java, I see this as a GUI-knowledgeable class.  The actions are essentially 
gui events, and many of them know about the gui, and have access to gui 
information via GuiPackage.java and other classes.  So, I see no problem with it 
having GUI code in it.  

It might, however, be useful to create an initialization method in the Command 
interface, and put this stuff there rather than in a constructor or static initializer.

-Mike

On 2 Jan 2003 at 12:00, Jordi Salvat i Alabart wrote:

> No, I remember having taken out that bit of code, but the reason was 
> that it was causing JMeter fail to start when the help.html file wasn't 
> available -- even when running the unit tests, since it happens at class 
> load time. This made the "test" target depend on the "docs" target, 
> which in turn means you need to have Anakia installed to build and test 
> -- which is something I wanted to avoid: I'd like the amount of work 
> needed by a new developer to fix a bug and test his patch kept to a minimum.
> 
> Before removing it, I tried to see it work, but it just didn't. Try it: 
> go to a clean 1.8 install, rename the docs directory, and try to start 
> JMeter. This is what you'll get:
> 
> java.lang.reflect.InvocationTargetException: 
> java.lang.ExceptionInInitializerError: java.lang.NullPointerException
> 	at org.apache.jmeter.gui.action.Help.<clinit>(Help.java:51)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:120)
> 	at 
> org.apache.jmeter.gui.action.ActionRouter.populateCommandMap(ActionRouter.java:185)
> 	at 
> org.apache.jmeter.gui.action.ActionRouter.getInstance(ActionRouter.java:220)
> 	at org.apache.jmeter.JMeter.startGui(JMeter.java:185)
> 	at org.apache.jmeter.JMeter.start(JMeter.java:237)
> 	at java.lang.reflect.Method.invoke(Native Method)
> 	at org.apache.jmeter.NewDriver.main(NewDriver.java:165)
> 
> I think this is because it's just too early to use GUI at this point.
> 
> So I thought it wasn't worth keeping around a bit of code which should 
> never be run on a binary dist, won't work anyway, and is there just to 
> warn you about a relatively minor problem which will show up in the log 
> anyway.
> 
> Makes sense?
> 
> Salut,
> 
> Jordi.
> 
> Wolfram Rittmeyer wrote:
> > Hi Jordi,
> > 
> > because of the reported WIN98-bug (14618) which occured in Help.java I just
> > diffed this file with version 1.6. Thereby I found something which I guess
> > is a result of your recent separation of tasks.
> > 
> > Up to version 1.7 a user got notified if an error occured during the
> > load-process of the help. Yet you took out this fragment because it would
> > cause a GUI-call which should not be made from a core-class (at least I
> > guess that's the reason).
> > 
> > I think this behavious is correct since I strongly support a separation of
> > gui and core-functionality. Yet shouldn't there be some kind of
> > notification? Maybe a thrown exception which the gui-part would be
> > responsible for to catch it? After all that's what you would expect from a
> > client-class, if it cannot fulfill the requested service, isn't it? Of
> > course this would mean quite some work on the gui-side.
> > 
> > I haven't searched around wether other core-classes have similar "issues".
> > If so, I would recommend a enhancement-request so that these issues do not
> > get lost over time. Do you (or anyone else) agree?
> > 
> > Though I guess right now there are some more urgent things to do...
> > 
> > Greetings,
> > 
> > Wolfram
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: error-handling

[Jordi Salvat i Alabart <js...@atg.com>]

No, I remember having taken out that bit of code, but the reason was 
that it was causing JMeter fail to start when the help.html file wasn't 
available -- even when running the unit tests, since it happens at class 
load time. This made the "test" target depend on the "docs" target, 
which in turn means you need to have Anakia installed to build and test 
-- which is something I wanted to avoid: I'd like the amount of work 
needed by a new developer to fix a bug and test his patch kept to a minimum.

Before removing it, I tried to see it work, but it just didn't. Try it: 
go to a clean 1.8 install, rename the docs directory, and try to start 
JMeter. This is what you'll get:

java.lang.reflect.InvocationTargetException: 
java.lang.ExceptionInInitializerError: java.lang.NullPointerException
	at org.apache.jmeter.gui.action.Help.<clinit>(Help.java:51)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:120)
	at 
org.apache.jmeter.gui.action.ActionRouter.populateCommandMap(ActionRouter.java:185)
	at 
org.apache.jmeter.gui.action.ActionRouter.getInstance(ActionRouter.java:220)
	at org.apache.jmeter.JMeter.startGui(JMeter.java:185)
	at org.apache.jmeter.JMeter.start(JMeter.java:237)
	at java.lang.reflect.Method.invoke(Native Method)
	at org.apache.jmeter.NewDriver.main(NewDriver.java:165)

I think this is because it's just too early to use GUI at this point.

So I thought it wasn't worth keeping around a bit of code which should 
never be run on a binary dist, won't work anyway, and is there just to 
warn you about a relatively minor problem which will show up in the log 
anyway.

Makes sense?

Salut,

Jordi.

Wolfram Rittmeyer wrote:
> Hi Jordi,
> 
> because of the reported WIN98-bug (14618) which occured in Help.java I just
> diffed this file with version 1.6. Thereby I found something which I guess
> is a result of your recent separation of tasks.
> 
> Up to version 1.7 a user got notified if an error occured during the
> load-process of the help. Yet you took out this fragment because it would
> cause a GUI-call which should not be made from a core-class (at least I
> guess that's the reason).
> 
> I think this behavious is correct since I strongly support a separation of
> gui and core-functionality. Yet shouldn't there be some kind of
> notification? Maybe a thrown exception which the gui-part would be
> responsible for to catch it? After all that's what you would expect from a
> client-class, if it cannot fulfill the requested service, isn't it? Of
> course this would mean quite some work on the gui-side.
> 
> I haven't searched around wether other core-classes have similar "issues".
> If so, I would recommend a enhancement-request so that these issues do not
> get lost over time. Do you (or anyone else) agree?
> 
> Though I guess right now there are some more urgent things to do...
> 
> Greetings,
> 
> Wolfram
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>