Any ideas how to avoid this code checker error?

[laredotornado]

Hi,

I'm using Java 1.5 on a Resin 3.0.19 web/app server. I'm using PMD as
the code-checker, and in an EJB, it is complaining about

public List<SubvendorCustomerRecord> getSubvendorCustomerReport(
final Integer subvendorId) throws RemoteException {
List<SubvendorCustomerRecord> results = new
ArrayList<SubvendorCustomerRecord>();
try {
AbstractReport report = new SubvendorCustomerReport(subvendorId);
results.addAll( report.getReportData() );
} catch (Exception e) {
LOG.error(e.getMessage(), e);
throw new RemoteException(e.getMessage());
}
return results;
}

Specifically the "throw new RemoteException(e.getMessage());" line,
with the complaint, "New exception is thrown in catch block. Original
stack trace may be lost." Does anyone know how I can rewrite the
above so that I can still log any error but at the same time get rid
of the annoying code-checker warning?

Thanks, - Dave

 

[Lew]

Other exceptions (not 'java.rmi.RemoteException' or some others) have a
constructor that takes just a 'Throwable cause' as an argument, the result of
which, according to

Constructs a new exception with the specified cause and a detail message of
(cause==null ? null : cause.toString())

Side notes:

- It is usually a bad idea to catch 'Exception'.
You should catch specific checked exceptions.

- 'LOG' does not follow the Java coding conventions:
<http://java.sun.com/docs/codeconv/index.html>

- Do not use TAB characters to indent Usenet code samples!
Use a maximum of four *spaces* to indent per level.
laredotornado, you've been around this group long enough to know better.

 

[Daniel Pitts]

Side notes:
- 'LOG' does not follow the Java coding conventions:
<http://java.sun.com/docs/codeconv/index.html>

I'm curios about this..

private static final Logger LOG = ...;

It is private, static, and final: Which convention would you use?

 

[Lew]

I'm curios about this..

private static final Logger LOG = ...;

It is private, static, and final: Which convention would you use?

Why, the one referenced in my post, natch. Surely you saw the reference; you
repeated it.

The names of variables declared class constants and of ANSI
constants should be all uppercase with words separated by underscores ("_")

otherwise they're in camel case with a lower-case first letter.

There's an apparent typo in the conventions spec, which confuses matters.

Except for variables, all instance, class, and class constants
are in mixed case with a lowercase first letter.

When clearly the intent is to say:
Except for class constants, all instance and class variables are in mixed case
with a lowercase first letter.

 

[Daniel Pitts]

Why, the one referenced in my post, natch. Surely you saw the reference;
you repeated it.

otherwise they're in camel case with a lower-case first letter.

There's an apparent typo in the conventions spec, which confuses matters.

When clearly the intent is to say:
Except for class constants, all instance and class variables are in
mixed case with a lowercase first letter.

And what defines a class constant? If you go by "static+final", then LOG
would be correct, and "log" would be incorrect.

 

[Lew]

And what defines a class constant? If you go by "static+final", then LOG
would be correct, and "log" would be incorrect.

The JLS, of course. From the same people who brought us the code conventions
document. However, I see that the section of the JLS on naming conventions
contradicts the conventions document. So I was wrong.

I was going by
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.28>
but brought up short by
<http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.8.6>

 

[laredotornado]

The JLS, of course.  From the same people who brought us the code conventions
document.  However, I see that the section of the JLS on naming conventions
contradicts the conventions document.  So I was wrong.

I was going by
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.htm...>
but brought up short by
<http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.8.6>

Hi,

Per the first suggestions, I used the constructor where I wrapped the
original exception and the code-checker stopped complaining.

I'm catching "Exception" because certain things like
"NullPointerExceptions" aren't prompted for by the compiler, and I
wish to log any type of exception before this call goes back to the
client calling my EJB.

Thakns for the help, - Dave

 

[Daniel Pitts]

Hi,

Per the first suggestions, I used the constructor where I wrapped the
original exception and the code-checker stopped complaining.

I'm catching "Exception" because certain things like
"NullPointerExceptions" aren't prompted for by the compiler, and I
wish to log any type of exception before this call goes back to the
client calling my EJB.

Thakns for the help, - Dave

I suggest having a few catch blocks then. The first one should be for
RuntimeException, where you can log it and then rethrow it directly.
The rest should be for the specific checked exceptions you wish to
catch. That way you can add specific error message per exception, and
only wrap the ones you need.

 

[Roedy Green]

Specifically the "throw new RemoteException(e.getMessage());" line,
with the complaint, "New exception is thrown in catch block. Original
stack trace may be lost."

You would have to save the trace, and rethrow it, or dump it there.

If you use IntelliJ, run the code inspector, and it will insert the
appropriate annotation to suppress the warning if you ask it to.

See http://mindprod.com/jgloss/annotation.html to do it manually.

http://mindprod.com/jgloss/intellij.html

 

[Roedy Green]

- 'LOG' does not follow the Java coding conventions:
<http://java.sun.com/docs/codeconv/index.html>

how can you tell without seeing his declaration for LOG?

 

[Lew]

how can you tell without seeing his declaration for LOG?

I explained my reasoning, and why it was wrong, upthread, but I'll recap for
your sake, since either you didn't read it, or didn't understand it. or didn't
read the links, or didn't understand them.

The code convention document (not the JLS, though) suggests using all
upper-case names only for class constants. The OP's code

LOG.error(e.getMessage(), e);

shows that 'LOG' is not a class constant. QED.

I was fooled by the fact that the JLS does not suggest the same convention.

 

[Wojtek]

Lew wrote :

I explained my reasoning, and why it was wrong, upthread, but I'll recap for
your sake, since either you didn't read it, or didn't understand it. or
didn't read the links, or didn't understand them.

The code convention document (not the JLS, though) suggests using all
upper-case names only for class constants. The OP's code

LOG.error(e.getMessage(), e);

shows that 'LOG' is not a class constant. QED.

In which way? Because LOG has a method?

Then what about a String? It has methods.

 

[John B. Matthews]

I explained my reasoning, and why it was wrong, upthread, but I'll
recap for your sake, since either you didn't read it, or didn't
understand it. or didn't read the links, or didn't understand them.

The code convention document (not the JLS, though) suggests using all
upper-case names only for class constants. The OP's code

LOG.error(e.getMessage(), e);

shows that 'LOG' is not a class constant. QED.

In which way? Because LOG has a method?

Then what about a String? It has methods.[/QUOTE]

I struggle with this, too. In _Effective Java_, item 56, Joshua Block
expands the notion of class constant to include static final fields
having a primitive type or an immutable reference type:

static final Random RANDOM = new Random();
static final Integer ANSWER = Integer.valueOf(42);

I'm not sure how to apply this to java.util.logging.Logger.

 

[Wojtek]

John B. Matthews wrote :

Roedy Green wrote:
quoted or indirectly quoted someone who said :

- 'LOG' does not follow the Java coding conventions:
<http://java.sun.com/docs/codeconv/index.html>

how can you tell without seeing his declaration for LOG?

I explained my reasoning, and why it was wrong, upthread, but I'll
recap for your sake, since either you didn't read it, or didn't
understand it. or didn't read the links, or didn't understand them.

The code convention document (not the JLS, though) suggests using all
upper-case names only for class constants. The OP's code

LOG.error(e.getMessage(), e);

shows that 'LOG' is not a class constant. QED.

In which way? Because LOG has a method?

Then what about a String? It has methods.

I struggle with this, too. In _Effective Java_, item 56, Joshua Block
expands the notion of class constant to include static final fields
having a primitive type or an immutable reference type:

static final Random RANDOM = new Random();
static final Integer ANSWER = Integer.valueOf(42);

I'm not sure how to apply this to java.util.logging.Logger.[/QUOTE]

And then you have enum. Which can have a constructor with parameters.
Which will then have methods to get at those parameters.

And an enum value is all upper case.

I am not confused at all. If it is static and final, then it is a class
constant. The fact that it has attributes which can be modified (if
exposed) is a moot point. The _reference_ cannot be changed, and so it
is a constant.

Where I use classes as constants, I also make sure that there are no
setters, which preserves the original state of the object.

 

[John B. Matthews]

wrote: [...]

Then what about a String? It has methods.

I struggle with this, too. In _Effective Java_, item 56, Joshua Block
expands the notion of class constant to include static final fields
having a primitive type or an immutable reference type:

static final Random RANDOM = new Random();
static final Integer ANSWER = Integer.valueOf(42);

I'm not sure how to apply this to java.util.logging.Logger.

And then you have enum. Which can have a constructor with parameters.
Which will then have methods to get at those parameters.

And an enum value is all upper case.[/QUOTE]

Bloch mentions this, also. I know I should should specify a more
readable name in the enum constructor and overload toString(), but
sometimes I am weak and rely on name():

I am not confused at all. If it is static and final, then it is a
class constant. The fact that it has attributes which can be modified
(if exposed) is a moot point. The _reference_ cannot be changed, and
so it is a constant.

Where I use classes as constants, I also make sure that there are no
setters, which preserves the original state of the object.

I'm more certain of this when the class is marked final.

 

[John B. Matthews]

[...] In _Effective Java_, item 56, Joshua Block
expands the notion of class constant to include static final fields
having a primitive type or an immutable reference type:

static final Random RANDOM = new Random();

At the risk of making it look like I care about the naming convention
aspect of this discussion when in fact I couldn't care less, I do
just have to point out:

The Random java.util.Random class (I'm assuming that's the type
implied above) is neither a primitive type nor an immutable reference
type.

Yes, thank you for clarifying.

It's very much mutable. It mutates every time you call one of
its declared members (i.e. any not inherited from Object).

Good point, hence my struggle. The class java.util.Random is neither
final or immutable, and yet it's behavior is entirely predictable once
constructed. It becomes an immutable, cyclic sequence, governed by the
seed and each call to the "next*" methods.

If the goal of a naming convention is to lend clarity, I'd have to go
with the context.

 

[Lew]

Lew wrote :

In which way? Because LOG has a method?

Then what about a String? It has methods.

None of which are named 'error()'.

Come on, people.

 

[Lew]

I am not confused at all. If it is static and final, then it is a class
constant. The fact that it has attributes which can be modified (if
exposed) is a moot point. The _reference_ cannot be changed, and so it
is a constant.

That is not the definition of a class constant! The JLS defines the term. It
is an extremely important distinction; initialization of class constants and
their storage differs from other 'static final' variables.

You are not using the correct definition.

 

[Lew]

Joshua Block...

It's Joshua Bloch, not Joshua Block. Get it right, please.

 

[Lew]

Uh, I admit I misspelled his name. But, I simply used the same spelling
John originally posted. Why single me out?

I'm not singling you out, I just didn't feel like citing every single post
that misspelled it, so I picked the most recent. If you hadn't made the same
error, I'd've answered the earlier post.

If John jumped off a bridge, would you do that, too?

Though, I admit…between the spelling of a person's name and the coding
conventions used in code not relevant to an actual project you're
working on, the former is much more worthy of mention.

Especially if you happen to share the same surname.