Supress Unhandled Exception inspection

Answered

Hi, I have this code, that calls a library that can throw an exception:

I don't want to handle that exception and I want to supress the inspection for that method.

In this article https://www.jetbrains.com/help/phpstorm/suppressing-inspections.html I see I should get an option to supress the inspection.

Instead, pressing `ALT` + `Enter` what I get is this:

and I can't just say "hey, do not warn me for this piece of code".

Question:

How can I supress the "Unhandled Exception" inspection for a particular piece of code in PhpStorm?

Thnx.

8 comments
Comment actions Permalink

Hi there,

In general: Alt+Enter menu is context dependant: it will show different items based on caret position. As far as I understand ... in your case caret should be positioned on "delete" part.

Try also "Code | Inspect Code..." and run it for current file -- you can apply suppressions from there as well (in case if it will not work via local Alt+Enter for whatever reason)

P.S. Instead of suppressing (which will add special comment into your code and will affect single statement only) .. why not just generate PHPDoc for this method and list any unhandled exceptions there via @throws tags -- it will cover whole method and will be more correct overall (suppression comments should not be used freely -- only when there is no other way).

1
Comment actions Permalink

Oh, I see, I did not know that PhpDocumenting it would remove the highlights!

In any case, it's not the exact case. When I do that, PhpStorm thinks this method will then throw the exception and this will carry-on over the calling stack.

In this case, I just know the exception will *not* be thrown and I just want to signal "hey, do not warn me".

What I've seen is that I can supress one line or the whole file. Can I supress inspection for a block of lines without cluttering with annotations?

0
Comment actions Permalink

Exception checking/handling is implemented similar to how it's done for Java in IntelliJ IDEA.

@throws tells IDE that you can throw such exception here in this method.. or it's thrown in one of the called stuff and you do not handle it here (so it will propagate to the upper level/parent).

 

>What I've seen is that I can supress one line or the whole file.

NOTE: whole file suppression may work since next major 2018.2 version only (not super sure -- menu item was available since very first version but was actually implemented just recently).

>Can I supress inspection for a block of lines without cluttering with annotations?

No.

Also keep in mind: while suppression comments do look like PHPDoc ones they are not treated as such. So if you need to suppress something that applies to function or field declaration (e.g. unused function parameter) and you already have PHPDoc comment for that function ... then suppression comment will be inserted separately and you cannot just merge it with existing PHPDoc content.

Suppression comment (when you tell IDE: silent this inspection here) should be used as very last resort. It's IDE specific and adds little value to a person that will use another IDE/editor. Actual PHPDoc comment (I'm referring to @throw tags) is much more developer-friendly in this regard (overall of course).

>In this case, I just know the exception will *not* be thrown and I just want to signal "hey, do not warn me".

I understand what you mean here -- exception will be thrown only if parameter is an empty string or of not compatible type etc. so will never happen with your code... but unfortunately it's not currently possible to document or detect and automatically silent such cases (no special annotations/functionality available).

The best you can do is:

  • Just document with @throw and allow to "handle" at upper level (and ignore it there .. or it may fall under general catch block) -- 1st/2nd best solution overall
  • If it's a unique exception and will happen only in such cases -- add it to the list of ignored exceptions in that particular Inspection settings. 1st/2nd best solution and the most cleanest (no comments of any kind -- all at IDE config level)
  • Suppress it for each line -- not a good idea overall (code will look messy cluttered with pretty useless IDE-specific comments)
  • Use try-catch block just for that exception -- looks absolutely pointless/provides no real run time value/dead code (as it will never happen due to the nature of throw logic)
  • Disable such inspection(s) altogether (that's if you think that IDE distracts more than helps here and you can handle it better yourself). NOTE: individual inspections can be disabled/configured on per Scope level (Scope may include individual files or whole folders etc)
1
Avatar
Vladimir Luchansky
Comment actions Permalink

It is also worth mentioning that you can suppress inspections for particular statements by pressing the Right arrow key to expand the list here:

List with inspection settings will appear where you need to select the correct suppress action and press Enter.

0
Comment actions Permalink

@Andriy Bazanov

Thanks for the detailed explanation. In fact, the conclusion to which I arrived is the following:

  1. I'm conscious that cluttering the code with IDE-specific notes is not good, but I definitively want to silence this occurence "here" and not in all the project.
  2. Thanks to talking to you guys and thinking about it I really saw there was a "code smell" there, specially regarding the block-thing.
  3. In fact what I should do is, instead of calling $this->connection->delete( xxx ) multiple times, call a wrapper method instead, in the same class: $this->delete( xxx ) and then in my own delete( zzz ) method call the $connection->delete( zzz ). This way the "call to the low-level library" is centralized in a single sentence.
  4. This allows me to "silence" only one single line, keep code readable, introduce IDE-specific things only in a single line and keep the code clean.

So the final option was your third bullet point but taking care to "refactor" the code in a way tominimize the visual effects of commenting each line and "dirtyness" of injecting IDE-specific things into the code, which I voluntarily choose in this case, but really if only once, better than if 5 times.

Conclusion: The "fact" of having the warnings set helped to organize the code better even if I just wanted to silence the warning.

@Vladimir Luchansky

Ah wow!!! I can ensure I really tried the "triangular caret" but with the mouse!!!

Maybe the developers at JetBrains should review the UX of this. It's not inctuitive that {if you click the "caret" with the mouse and nothing happens, then something will happen if you do things with the keyboard}.

Pressing the right-arrow when the option is selected really reveals another submenu that I could not show with the mouse!

Thanks to all for your help! Topic closed.

1
Avatar
Vladimir Luchansky
Comment actions Permalink

@Xavi Montero You can click that triangle with mouse and submenu will be shown as well.

Does it work differently for you?

0
Comment actions Permalink

Indeed... When I clicked the triangle no submenu appeared... just "the option" that contained the triangle was executed.

That happened with 2018.1 EAP. Today I installed 2018.2 EAP, I've not tried with the new one. Will test and tell.

0
Comment actions Permalink

>Indeed... When I clicked the triangle no submenu appeared... just "the option" that contained the triangle was executed.

The clickable area is quite small when doing it with the mouse -- has to be somewhere close to the very right end IIRC. Keyboard way works more stable (always).

2

Please sign in to leave a comment.