Print

Print


Bob is refering to the Particle.getType() method, which throws an
UnknownParticleID exception if the Particle type is not in the list of
known particles. This frequently happens in analysing the events
generated by pythia, since Pythia inserts a particle with PDG code 21,
which corresponds to a "string" but is not in the list of known
particles. The workaround is to trap the UnknownParticleID, for example:

	try
	{
         	histogram("particle
type").fill(type.getType().getName());
	}
	catch (UnknownParticleID x)
	{
		histogram("particle type").fill("Unknown");
	}

To answer Bob's question, I think that it is better to throw an
exception than to have a special return code, for two reasons:

1) Since getType() returns an object, the only possible "special" return
code would be null. But in the above case that would result in the
getName() operation throwing a NullPointerException. People whose code
unexpectedly throws a NullPointerException are likely to be much more
confused that people whose code throws a UnknownParticleID, since the
former gives no hint as to what is wrong. To avoid the
NullPointerException you would need to always test the return code of
getType() which, even if you always remembered to do so, would result in
code clutter.
2) Exceptions are just the right way to handle this sort of thing.

We could add the Pythia code 21 object to the table of known particles,
but it is unclear what the various ParticleType methods should return
for such an object, and it would be impossible to add all types of
"special" particles which could be returned by any generator.
Nonetheless I am happy to add this particle if people think we should do
so.

What are the complications that you mention?

Tony

-----Original Message-----
From: Robert J. Wilson [mailto:[log in to unmask]]
Sent: Friday, April 09, 1999 1:57 PM
To: [log in to unmask]
Subject: How to get at the monte carlo truth hierarchy etc.



Is there a strong reason for the getType() method to throw an exception?

Even though Tony gave me a work around it is still causing complications
which I don't understand. A java level exception seems unnecessary,
perhaps just a  gentle return code would make user code easier to
handle.