A non-numeric value encountered

[garyed]

Is there any way to disable the "A non-numeric value encountered" warning in the php.ini file? I don't get that warning on my Apache server but I do when I use the same code on my web host's server.  I never got the warning until I uploaded a two line  php.ini file to my web host so that I could keep my sessions longer than the default 24 minutes. This is the same online program related to my earlier post about too many inputs. I wanted to try sessions for a 24 hr. period but I'm getting  tons of errors for any field that is not used which can be in the hundreds. If I delete my php.ini file from my web host & just let things default to whatever they are using then I don't get those errors,  

[Barand]

Seems to me that the best approach would be to fix the problem instead of disabling the warning.

[garyed]

If I didn't have so many errors I would agree but after spending an hour or two fixing some of those errors & seeing how long it was going to take to fix all of them I figured there's got to be an easier way. The program has been running fine for years on the same server & what is being called errors now have never had any effect on the functionality. I'm not saying it's the right way or the best way but I just don't see a need to fix anything if I can just get rid of the messages.  Remember the error messages only appear when I add a two line php.ini file to the server to extend the session time. So I'm assuming it has just as much to do with the .ini file than the coding. It also runs fine on my server & I'm running PHP 7.2.24 where my web host is running PHP 7.2.33 so I assume there is a way to do something in the ini file. I just don't want to spend a couple days fixing errors for no reason if I can fix everything with a single line.        

[garyed]

I found the answer & it was pretty simple.  All i had to do was add  the line "display_errors = Off" in php.ini & everything works just fine. Now I have to decide if I really want to do the work to correct all those non-numerical values or not. Other than not being notified of errors, does anyone see it causing a problem with functionality?      

[requinix]

1 hour ago, garyed said:

All i had to do was add  the line "display_errors = Off" in php.ini & everything works just fine.

Removing the battery from a fire alarm does not make the fire go away.

[garyed]

1 hour ago, requinix said:

Removing the battery from a fire alarm does not make the fire go away.

The problem is that I don't have any fires that I know of.  The same code has been running smoothly for quite a few years. If I was having problems then it would make more sense to me. I may end up changing the code to get rid of the errors anyways but what harm does it do to have a non numeric value that is not being used? That's my question & if I hear a good reason to get rid of those non numeric values that wopuld help me make up my mind. I just don't want to throw in 50 or 100 if statements & arrays that don't help anything except keep errors from being displayed when i can accomplish the same thing with two words in an ini file. I'll know better in the future to be more careful with unused fields but I don't want to rewrite something that's already working & not get any better results..  

[kicken]

39 minutes ago, garyed said:

...that is not being used?

If it was not being used, you wouldn't be getting an warning.  Since you are getting a warning, it means something is being used incorrectly.

What you need to do is figure out what is triggering the warning and why.  A quick google search for that message suggestions a common cause for this is trying to concatenate strings using + (plus) instead of . (period).  

Using an empty string in a calculation seems to be another cause, and this may be your problem as a blank input is the empty string.  You would fix this by converting those empty strings to zero prior to using them.  This could be done relatively easily using array_map.

Edited September 17, 2020 by kicken

[Phi11W]

11 hours ago, garyed said:

 I just don't see a need to fix anything if I can just get rid of the messages.

Do you also drive your car with all the dashboard indicator [warning] lights covered up? 

Sorry but, to me, this is just absurd.

You need to get your site into surgery and "operate" on it, to fix the underlying problems, not just whack a Band-Aid on it and hope for the best! 

Sooner or later, one of those [ignored] warnings/errors is going to actually break your site and, suddenly, it'll be "all hands to the pumps", trying to get your site back up and running again, against a tidal wave of errors only one of which is the actual trouble-maker, and you'll [possibly] be losing money the whole time you're doing it. 

Surely it's got to be better to take the time and trouble to do that investigative and corrective work now, before the heat is on? 

 

9 hours ago, garyed said:

Other than not being notified of errors, does anyone see it causing a problem with functionality?

We don't know what your application is or what it is supposed to do, so it's impossible for us to comment. 

I'm just hoping it isn't in the Nuclear Power industry ...

$config->maxCoreTemp = 'q' ; 
. . . 
$reactor->shutdownIfTemperatureExceeds( $config->maxCoreTemp ); 

Regards, 
   Phill  W.

 

 

[garyed]

6 hours ago, kicken said:

If it was not being used, you wouldn't be getting an warning.  Since you are getting a warning, it means something is being used incorrectly.

What you need to do is figure out what is triggering the warning and why.  A quick google search for that message suggestions a common cause for this is trying to concatenate strings using + (plus) instead of . (period).  

Using an empty string in a calculation seems to be another cause, and this may be your problem as a blank input is the empty string.  You would fix this by converting those empty strings to zero prior to using them.  This could be done relatively easily using array_map.

You are absolutely correct. All the errors I'm getting is from using empty strings in my calculations. I started fixing them by putting some of them in an array & then using array_sum which gets rid of the errors when empty strings are added together. Also zeroing out some worked too depending on the calculation but there are so many to do it was getting a little frustrating. I wanted to see if it was feasible to just not show the errors & by doing so everything is working just fine. Since the only errors are from using empty strings, I'm really just trying to find out what the down side is to using an empty string in a calculation other than displaying the error. I am already totally convinced that it is wrong to do but I'm just not convinced of the necessity to fix anything if its working.        

[kicken]

1 hour ago, garyed said:

I'm really just trying to find out what the down side is to using an empty string in a calculation other than displaying the error.

In your particular use case, there may not be a real downside, but that doesn't hold true for all use cases and the operation in general is wrong.  That's why the warning exists.

When PHP needs to do a string to integer conversion, but the string is not a valid integer you end up with zero.  In your case, that's probably what you want to happen so it "works".  It's a sign of possible bug though so the warning is there to alert you to check your code.  The proper thing to do is first validate your input so you know it's a valid number, and maybe even convert it yourself while your at it.

As I mentioned, this could potentially be easily done with a simple array_map operation depending on your input needs.  If all your inputs should be numbers, you could do something like this:

$data = array_map('floatval', $_POST);

Then just use $data['blah'] in your calculations.  Any empty strings (or invalid numbers) will have been converted to zero, and any valid numbers will have been converted to a really number type.

If only some of your inputs need to be converted, then you can do similar to the above, but limit the scope to the necessary inputs using array_intersect_key.

$data = array_map('floatval', array_intersect_key($_POST, array_flip(['list','your','input','names','here'])));

Yet another alternative is to create a function to grab your input values and let it handle the conversion. 

function getInputNumber($field){
	return floatval($_POST[$field] ?? 0);
}

Bottom line is there are many ways to solve the empty string problem without having to do a massive amount of code modifications.  The changes required could be nearly none (if you say re-assign $_POST) or easily handled via a find/replace function in your editor.

 

Edited September 17, 2020 by kicken

[garyed]

39 minutes ago, kicken said:

In your particular use case, there may not be a real downside, but that doesn't hold true for all use cases and the operation in general is wrong.  That's why the warning exists.

When PHP needs to do a string to integer conversion, but the string is not a valid integer you end up with zero.  In your case, that's probably what you want to happen so it "works".  It's a sign of possible bug though so the warning is there to alert you to check your code.  The proper thing to do is first validate your input so you know it's a valid number, and maybe even convert it yourself while your at it.

As I mentioned, this could potentially be easily done with a simple array_map operation depending on your input needs.  If all your inputs should be numbers, you could do something like this:

$data = array_map('floatval', $_POST);

Then just use $data['blah'] in your calculations.  Any empty strings (or invalid numbers) will have been converted to zero, and any valid numbers will have been converted to a really number type.

If only some of your inputs need to be converted, then you can do similar to the above, but limit the scope to the necessary inputs using array_intersect_key.

$data = array_map('floatval', array_intersect_key($_POST, array_flip(['list','your','input','names','here'])));

Yet another alternative is to create a function to grab your input values and let it handle the conversion. 

function getInputNumber($field){
	return floatval($_POST[$field] ?? 0);
}

Bottom line is there are many ways to solve the empty string problem without having to do a massive amount of code modifications.  The changes required could be nearly none (if you say re-assign $_POST) or easily handled via a find/replace function in your editor.

 

Thanks for the ideas, I'll look into them & see if it would be more practical than what i was doing to get rid of the errors. I started thinking that even though everything is working fine now, that down the road when my web host changes to another version of PHP or anything in their settings that I have no control over, those errors could come back & bite me. So I think you guys are right that I should take the time to clean the code up now & not just leave it alone because it's working. I'm in the HVAC business & a lot of times you can get something working temporarily even though it's not right. If you don't go back with the right part or whatever it takes to get it right then down the road it causes a problem. I'm starting to look at my php code the same way, that it needs to be error free  or it can hurt you in the future. Thanks again to everyone for the advice        

[garyed]

I just wanted you guys to know i came up with a pretty simple solution for most of the errors. It may not be right but it works pretty good. It just converts all the empty spaces to zero. I couldn't check for just numbers because there are too many hidden values that are posted that are not numbers so I just checked for empty fields.  

 

foreach($_POST as $key => $value) {
if ($value=="") {
$_POST[$key]=0;
}
}

I needed to add a few more if statements to get rid of division by zero errors & everything seems to be working OK & all the errors are now gone.