This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 230548 - "Use specific type in catch" is wrong for RuntimeExceptions
Summary: "Use specific type in catch" is wrong for RuntimeExceptions
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 7.4
Hardware: PC Windows 7
: P3 normal with 1 vote (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-30 19:41 UTC by _ gtzabari
Modified: 2013-11-08 03:54 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2013-05-30 19:41:07 UTC
Product Version: NetBeans IDE Dev (Build 201305232300)
Java: 1.7.0_21; Java HotSpot(TM) 64-Bit Server VM 23.21-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_21-b11
System: Windows 7 version 6.1 running on amd64; Cp1252; en_CA (nb)
User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev

1. Given:

		try
		{
			long rows = SQLUpdateClause.execute();
			if (rows != 1)
				throw new EntityNotFoundException("Call id not found: " + id);
		}
		catch (QueryException e)
		{
			// do something
		}

2. EntityNotFoundException extends QueryException which extends RuntimeException.
3. SQLUpdateClause is defined by QueryDSL-sql (a 3rd-party library).
4. SQLUpdateClause.execute() throws QueryException. The Javadoc mentions QueryException but the method signature does not contain it (since "throws" is optional for RuntimeExceptions).
5. Netbeans warns "Use specific type in catch" for "catch (QueryException e)".
6. Removing "throw new EntityNotFoundException" makes the hint go away.

So, I can either go around asking library authors like QueryDSL to add "throws" to their method signatures (I think it's safe to assume some/all of them will ignore me) or (sad to say) Netbeans cannot provide this hint for RuntimeExceptions.

In the above case, Netbeans cannot assume that execute() will not throw QueryException, hence it cannot assume I can catch a more specific type.
Comment 1 _ gtzabari 2013-10-04 15:43:57 UTC
Svata,

This involves a simple fix (simply skip this hint for subclasses of RuntimeException). Any chance you can fix this in the dev branch?
Comment 2 Svata Dedic 2013-10-04 16:59:46 UTC
Is there a reason the QueryException cannot be configured in 'Ignore umbrella exceptions' list in Options - Hints ?
Comment 3 _ gtzabari 2013-10-04 17:26:13 UTC
1. Oddly enough, it doesn't work. I even tried adding java.lang.RuntimeException as an umbrella exception but the warning remains.

2. Even if I could set this, I'm not sure it's appropriate. By default this field contains "java.io.IOException" and "java.sql.SqlException", meaning legitimate matches that need to be suppressed due to the user's personal preferences. In my case, we're talking about suppressing false positives, not just due to personal preferences.

3. I don't think it makes sense to ask users to suppress individual false-positives one by one. I guess in theory they could just add "java.lang.RuntimeException" but again I believe this should be enabled by default.

4. On a side-note, you should fix "java.sql.SqlException" (from #2) because the class name is really SQLException (notice the capitalization).
Comment 4 _ gtzabari 2013-10-04 17:27:05 UTC
For #1, you should be able to reproduce the problem using project-level hints in build 201309270002 (Maven project).
Comment 5 Svata Dedic 2013-11-06 09:50:55 UTC
Based on the explanation, the QueryException is indeed an 'umbrella' exception. It's the same situation as e.g. DataAccessException in Spring - it's perfectly valid to catch it, but blindly disable all RuntimeException sub-hierarchies is not an option.

You hit an uncovered case - if there were more Exceptions subclassing QueryException thrown from the try block, the QueryException would be recognized as an umbrella / common supertype and if it was in umbrellas list, no hint would be generated.
I'll add a special case when just one exception type is thrown AND the caught type is a defined umbrella extending RTE - supposing that the try-block code might generate more exceptions falling in that hierarchy.
Comment 6 Svata Dedic 2013-11-06 10:43:12 UTC
Fixed in http://hg.netbeans.org/jet-main/rev/2a432f41c46b
Comment 7 Quality Engineering 2013-11-08 03:54:21 UTC
Integrated into 'main-silver', will be available in build *201311080001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/91e4cf625683
User: Svata Dedic <sdedic@netbeans.org>
Log: #230548: Umbrellas deriving from RTE will not be reported even though they mask just 1 exception type