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.
If I have this code: try { <code throwing exceptions A and B> } catch (Exception ex) { <do something> } and let the ide generate catch handlers for specific (declared?) exceptions, i obtain code like this: try { <code throwing exceptions A and B> } catch (A ex) { <do something> } catch (B ex) { <do something> } which behaves differently at runtime, because it does not catch the runtime exceptions. Probably (at least for the sake of java newbies) it should add a catch block for runtime exceptions.
Please note the hint description: "Such broad catches may provide ... overly general exception handling". The reason why the hint was introduced is to catch only minimal set of exceptions, which is usually the safe way with respect to exception handling. Runtime exceptions should be used sparely and most probably handled centrally. For reasoning, google the Internet on topic related to checked/unchecked exceptions usage, exception (or catch) barriers, and design of error condition in layered systems. If you would suggest a description wording that explains better the hint's effect and/or things to be careful about, I'll be happy to use it.
I am conscious of the checked/unchecked exceptions debate and I am not questioning the motivations behind this particular hint - I agree with them. On the other hand, I think that changes made by the ide should never affect the runtime behavior of the user's code.
Lahvaci - you're the java hint owner / policy maker ;) please decide. On one hand, aldobrucale is right that suggestion code transformations should produce a functionally equivalent code. On the other hand, the purpose of the hint is break catch-all clauses in user code.
(I apologize for mentoring here) I personally don't believe in generalizing approaches like "The IDE should not change runtime behaviour." or "The IDE should never generate uncompilable code.". The main intent behind all the IDE features is to be useful - that sometimes means changing the code in a way that the runtime behaviour will change, or generating uncompilable code (*). But, in this case I don't feel strongly that the change in behaviour is warranted (and may actually be pretty hard to find). On the other hand, catching RuntimeException is usually pretty strong code smell, so if the catch is generated, it may be flagged as such. Right now, I incline to including the RuntimeException catch, and possibly adding an option. But I'd like to think about it some more. In the longer term, it may be appropriate to enhance the refactoring API&hints API with an ability to mark changes as "need review", and show these differently in the refactoring preview. We have some more hints that generate code that may require user's attention (or generate/will need to generate code too defensive in a general case). (*) As an example: we have a warning on String.replaceAll(".", ...), which converts that into String.replaceAll("\\.", ...). That undoubtedly changes to the runtime behaviour, and the sole purpose of the hint is to correct the almost surely wrong behaviour.