I want to suppress (disable) a waring in PhpStorm a message "Member has protected access" for a certain places (not in all code).
Example:
What I have tried
Link 1: on Alt + Enter I do not have anything connected to the message so that I could disable it. As well as I do not have this message in inspection results when Running Inspections.
Link 2 I do not have the message in Inspection Settings so I can not disable it.
Another try: using #noinspection. Here and here I did not find needed message.
There were suggestion to disable suppress all errors with Editor -> Colors & Fonts -> General -> Erros and Warnings -> Errors. But it is not what I need.
Is there no way to do it?
What you could do is implement the __set magic method into your class, which will transform these warnings into "notices".
/**
* #throws \Exception
*/
public function __set($name, $value) {
throw new \Exception(sprintf('Property "%s" does not exist in %s.', $name, __CLASS__));
}
Since PHPStorm can't analyse your code to make sure this property is settable through the magic method, it can't know whether it's an error or not.
Of course, it's kind of an ugly workaround, and means that runtime "Cannot access protected property" fatal errors will now be exceptions, which may or may not be fine in your case.
Related
I have a complex PHP project that contains two definitions for a function foo. One of those is in a vendor library, and I never use it, the other one I use a lot. The implementation in the vendor library throws an Exception, the correct implementation does not. Now anytime I write a function that calls foo(), PhpStorm's code inspections say I should declare a #throws \Execption in the caller's PhpDoc. I'd like to suppress that warning in this case, and maybe tell PhpStorm that I will never use the function in the vendor library.
I've experimented with Scopes, but couldn't make that work - I can prevent PhpStorm from reporting warnings in the vendor files, but not from analyzing them for symbols used in my own code.
Add /** #noinspection PhpDocMissingThrowsInspection */
or /** #noinspection ALL */ (for disable all inspections) at the top of method foo()
Background
I use several helper functions to stop the program flow and return data. For example, while most pages are HTML I occasionally return JSON and call
/**
* #param array|bool $response
*
* #die
*/
function jsonResponseDie($response)
{
header('Content-Type: application/json');
echo json_encode($response);
die();
}
The Problem
However, the calling function does not detect that there is a die statement and allows code to be present after it without warning.
function recievePush()
{
// Process a push request and respond with a json array.
jsonResponseDie(array('status' => TRUE));
echo 'This will never execute but PhpStorm doesn\'t know that';
}
The Question
How do I get PhpStorm to detect this function will die?
I did try a few items "#return die" or "#die" but these do not appear to be recognized. I also reviewed some documentation here but found nothing useful.
There is no special tags for such stuff in PHPDoc. PhpStorm also does not have any solution to that yet.
https://youtrack.jetbrains.com/issue/WI-10673 -- watch this ticket (star/vote/comment) to get notified on any progress.
UPDATE 2020-10-20:
The aforementioned ticket has been implemented and such functionality is now available since PhpStorm 2020.1.x version.
It is implemented using Advanced Metadata functionality (by creating separate PHP-like file for IDE eyes only): https://www.jetbrains.com/help/phpstorm/ide-advanced-metadata.html#define-exit-points
<?php
namespace PHPSTORM_META {
exitPoint(\App\PageFlow::exitApplication());
}
Another example: as a result, the terminate() call with the bar argument provided will act as an exit point (another value will not trigger this). The last line of the run method will therefore be treated as unreachable:
exitPoint(Application::terminate('bar'));
P.S. From PhpStorm 2020.3 (to be released at some point in December or so this year) and using PHP Language Level = 8.0 you will be able to use PHP 8-style attribute #[NoReturn] right in your code instead of separate Advanced Metadata file (see WI-55531 (actual/original implementation) and WI-56103 (new attribute name) tickets).
I have a CodeIgniter 3.1.11 project that I wanted to implement an exitPoint on my SendJsonResponseAndDie() method which is in my myproject/ci/application/helpers/format_helper.php file.
For me, the solution was as simple as creating a meta directory in myproject, then creating a .phpstorm.meta.php file with the following contents:
myproject/meta/.phpstorm.meta.php:
<?php
namespace PHPSTORM_META {
function exitPoint($functionReference) {
return "exitPoint " . $functionReference;
}
exitPoint(\SendJsonResponseAndDie());
}
Hey presto, the "unreachable statement" text appears whenever I mouseover code that occurs after the function call anywhere in the project.
I wish, though, that the lines of code that cannot be reached would be dimmed so that I am visually drawn to the problem instead of requiring my hover event.
Some additional reading not mentioned in #LazyOne's answer: https://github.com/JetBrains/phpstorm-stubs/blob/master/meta/.phpstorm.meta.php
If I let the code inspection run through my CakePHP project code all magic methods like findById() or findAllByName() are marked as "undefined".
In the background they call the __call() method of the Model.php class.
Is there an option that those are not marked as an error any more? It is spamming my inspection output. Not a serious problem, but it would be nice to get rid of an error, which is not an error.
I'm working on some flash app. Now, to test customer side of it I can use Flash Player debugger version that will save logs and show error messages. When it's deployed on the customer side - they will have a regular Flash Player version which means I will have no access to error messages if errors will happen. So I would like to equip it with some tool that would capture all of my trace messages in code and errors text. As for trace messages that's fairly simple, I just override the function in my code so it sends a POST request with trace message to a logger server, but how can I get a hold of the error message? Is there a known approach to this or some trick that somebody can suggest?
You can install the debug version of flash as your browser's default (in Chrome, you must disable the built-in player), so if you wanted to test user experience and debug, this would be the ideal solution.
However, to answer your question: there's no method for universally catching all errors, and redirecting them (that I know of). You'd have to encapsulate problem code ahead of time with try...catch statements, and send the property back on catch. For example:
try {
this["foo"]();
} catch (e:Error) {
trace(e);
}
In the debug version, the traced value would be TypeError: Error #1006: value is not a function. And while the standard version will only output TypeError: Error #1006, (a notably less descriptive error), what we're missing is any reference to where the error occured. To get this, we need to use Error.getStackTrace() to see the call stack and the line where the error occurred. In debug, this outputs the following:
TypeError: Error #1006: value is not a function.
at Shell_fla::MainTimeline/init()[C:\Projects\shell.as:91
In the standard client, we get a dissapointing null. In short, you cannot get any valuable info from the client versions.
The best advice I can give is to write around your problem code with your own custom error reports. For example, catch IO errors and trace the file it failed to load, or if you're expecting an object.foo, first try if (object.hasOwnProperty("foo")) { // do something } else { trace("foo not found in " + object.name) }. Code defensively.
Cheers,
I've discovered this post on StackOverflow:
How to catch all exceptions in Flex?
It answers my question, strange that I haven't ran into it while I was googling prior to asking.
While I'm developing my MS Access application, I open it with shift click. When an Error occurs, that is not trapped (by ON ERROR ...), a message box pops up informing me about the error. This is a good thing.
When a user open my application, he does't shift click, and an appropriate Start Form opens. However, now untrapped Errors don't show up, the application behaves as if the user clicked the Stop Button on the message box. I don't want this behaviour.
Is there an option / property / variable that provides the same behaviour in the production code (preferably even when the application id converted to an mde) as in development, i.e. show a message box for every untrapped error? Or is it neccessary to trap errors in every single event routine and pop up a message box by program?
It turns out, this is a side effect of setting the AllowSpecialKeys property to False. This can be done programmatically, but I did it in the menu under Tools > StartUp.
Since this property allows the user to open the code editor, it kind of makes sense, but the relationship of the phenomen described to this option was puzzling for me.
Does this mean, that if I want to hide my code, I need to write all those error handlers? Or is there one central place (like a main method in Java) where I can invoke an error handler. Alternatively, could I allow specical keys and just protect the code with a keyword?
You can create your own error handler and add it to all procs, subs and functions. You have this very nice MZ Tools VBA add-on that allows you many thing such as adding line numbers to your code, "preprogramming" your error label, etc.
If you are smart enough, you'll be able to use this add-on to generate a standard "error management" code displaying things such as err.number, err.description, and the undocument erl value, which is the number of the line where the error occured (you must first have your lines numbered before being able to get this value).
EDIT: I just opened this question on a similar subject.
As alluded to, MZ-Tools 3.0 is a great tool to aid in quickly adding error handlers. Also remember that errors which occur in procedures without error handlers "bubble up" to the last-invoked On Error statement. (And if no statement exists you get the little gray debug box.) The net effect of this, is that you can do minimal error handling by simply adding error handlers only to those procedures which are Public (or Friend) or called by event. This will make sure you always have at least 1 "top level" error handler invoked. If you want to add special handling to your private procedures after that feel free. If not, when an error occurs in them they will "bubble up" to the top level error handler.