0

with warning, I mean warnings that are not important or breaking, and not wrong code per say.

for example, imagine I have a search page.

 $query, $items (as in how many items to display)

and I would still supply the page with only $query, and I would use some default value for $items.

Now, since my code is basically

 $query = $_GET["query"];
 $items = $_GET["items"];

after this I can write such code to show items,

if (empty($items))
   //show default number of items
else
   //show set amount of items

Of course I would need to check if items is not number and stuff like that, but the basic idea is this.

This obviously throws warning "items" is not set. To fix this, before doing $items, I can check if "items" exists, and maybe if it exists set it to that amount and if not the default amount. This would throw nothing. However this only makes my code either longer or just the same logic at different place. I would still need to check if $items is number and tons of other stuff anyway, its not only one check either, although it is still short in this case. At best case, I would end with basically same thing in different place.

So what should I do? Make php ignore warnings for error_log ? Or should I make sure this errors never happen even if it doesnt change how the code works and make my "uglier" ?

Are warnings, warnings or just suggestions?

user3002686
  • 63
  • 7
  • possible duplicate of [Is seeing Notice in the HTML of any concern for PHP?](http://stackoverflow.com/questions/21035311/is-seeing-notice-in-the-html-of-any-concern-for-php) – John Conde Jan 11 '14 at 22:36
  • Warnings should always be addressed: if nothing else, there's a performance overhead simply in the basic PHP handling of warnings and notices; but they can also be indicative of (or even cause) other problems in the code – Mark Baker Jan 11 '14 at 22:41
  • For reference, the messages about undefined variables/offsets are notices, not warnings. A warning should definitely be avoided / fixed; it means something's pretty wrong, but not wrong enough to kill the app for *yet*. A notice is like "hey, this might might be quite right"...but if you know it is, it can safely be ignored (though a bunch of people will argue that ignoring them is unprofessional). – cHao Jan 11 '14 at 22:42
  • I wish PHP provided an easy way to specify which types of notices to ignore. This particular one irks me, and leads to code that shouldn't be needed if you *know* `$_GET['items']` may not exist, but care about avoiding notices. – cHao Jan 11 '14 at 22:51
  • Ignore my comment trying to use SO phone app and it sucks. – Rottingham Jan 11 '14 at 23:07

1 Answers1

0

After some research and a bit of thinking, I have written sensible variations of the code above. the solutions always, naturally, include using $_GET or ignoring errors/warnings/notices. this is not ideal.

I thought to see if filter_var would be useful for this, it is not.

I have created several solutions and the most feasible one seems to be having a function for $_GET

example:

    function setVar($v){
        if (isset($_GET[$v]))
            return $_GET[$v];
                       }

As expected, this will be just a reference to the original variable so nothing is changed. Except it wont throw notices. (isset and such will still work for unset/empty parameters as I dont return anything if it fails anyway) and GET/POST etc. will work in all scopes so I can use this in a "functions.php".

Also on a side note, for php 5.3 and below, it seems you can use(while 5.4 & above causes error)

function x($_GET...

while it is not exactly traditional, I dont think it would be much different to use setVar('var') rather than $_GET['var']

user3002686
  • 63
  • 7