The the PHP manual page about the exit construct states:
exit — Output a message and terminate the current script
Based on that, would it be correct to think that it violates the single responsibility principle?
No, because exit is a procedural language construct, not a member function of any class. The single responsibility principle is supposed to apply to object-oriented programming, something which does not encompass the entire basis of the PHP language (only a portion of it).
Technically, yes. However the exact violation isn't that bad... The Single Responsibility Principle is actually an abstract principle that can be applied to any unit of code. In Steve McConnell's Code Complete 2, he actually talks about this as cohesion. In practice, this is a more specific form of the single-responsibility-principle used for routines.
The most desirable kind of cohesion according to him is functional cohesion where a routine performs one and only one operation (the examples he shows are sin(), getCustomerName(), eraseFile(), etc). So, exit() does 2 things. Therefore it shows Temporal cohesion (the operations are done in the same routine because they are done at the same time).
Now, the original arguments to exit($arg) was the return status of the applicaiton (See: linux exit status codes). In C, this is the integer value returned from main(). But since PHP doesn't have a native function, it was added in to the exit() parameter. Try it, add exit(2), and the return value of the program will be a status 2 (0 is usually success, see are there any standard linux exit status codes).
However, since PHP has a low barrier to entry, most developers likely won't know about status codes. So, it was made to accept a string. If the argument is a string, the status is echoed out on STDOUT, and then the application terminates. If it's an integer, it'll be returned from the program. So it's an artifact.
Now, is it a problem? Not really. Is it ideal? No. But it's also not horrible, since they are related. In the end, I wouldn't lose sleep over it...
Related
First of all - there seem to be many questions about the fundamentals of tick functionality, so I want to add the top user comment at php.net/declare to the pile for anyone looking for further information. I found it while digging around as I tried to figure out the following.
So, I'm working on writing a simple debug helper. I want to add function tracing and benchmarking - basically what tick functionality is perfect for.
Thing is, I want to enable and disable benchmarking depending on arbitrary conditions that occur during script processing. I'm not really looking for fixed debugging à la scoped declare() { ... }.
What I'm looking to do is to put declare(); at the top of my script, and then register and unregister my debugging/benchmarking (tick) function as appropriate. Un/registration won't happen (too) often, so is efficient and reasonable.
But then I got curious: when I don't have a tick function registered... does the fact that I've run declare(ticks=1); have any effect on execution efficiency? Does it cause any extra processing to become permanently enabled anyway?
Analysis of PHP(7)'s source code shows that the answer is technically yes, but I'm not yet sure how.
The answer seems to be in zend_compile.c:8200: it appears this function defers compilation processing to the appropriate routines, then if ticks are enabled it additionally emits a ZEND_TICKS opcode into the opline via zend_emit_tick() in :2167. The opcode reference page for TICKS seems consistent with this conclusion; it shows an example disassembled opcode listing which has TICKS opcodes scattered throughout it, and I was wondering how they got in there until I discovered the above.
The ZEND_TICKS handler (in zend_vm_def.h:6859) seems to call zend_ticks_function(). This is mapped to ticks_function() in zend.c:754, which is in turn mapped to php_run_ticks() in main.2013. This is finally defined in php_ticks.c, where it's all of:
void php_run_ticks(int count)
{
zend_llist_apply_with_argument(
&PG(tick_functions),
(llist_apply_with_arg_func_t) php_tick_iterator,
&count
);
}
Huh. Not bad.
But here's the thing. If I declare(ticks=1);, the above dispatch is being run for literally every statement executed. That's... ouch. For long-running scripts containing high-iteration-count, tight processing loops, I'm wondering how badly that'll add up.
Problem is, I'm not even sure how to benchmark this. The only way I could envisage to do so would be to synthesize some PHP bytecode and then figure out a way to inject that directly into the PHP bytecode interpreter.
And that leads to my question: how much of a performance impact does this additional dispatch have, in practice? How can I quantify it?
Obviously the above investigation was performed on the canonical PHP.net interpreter. I haven't looked into how HHVM does this at all (yet), but I wouldn't at all mind learning how it handles it.
I read an interesting quote on a Python forum that it's "easier to ask for forgiveness than it is to ask for permission". I'm not too familiar with the language so I can't say whether this is garbage. From working with .NET, it is my understanding that a try catch is an expensive operation and should be there for exception cases only. Kind of like a safety net.
Is there any merit to this type of behaviour with php? As in, is it quicker to read from a file inside a try catch vs checking to see if the file can be found / read before performing the read operation. I can see how it makes the code easier to maintain, but what are the perfoance implications. Is it more of a waste to check when 99.9% of the time the check is pointless.
To the best of my knowledge, this is not a standard practice in PHP. This is, in large part, because most PHP builtins threw PHP errors -- not exceptions! -- prior to PHP 7.0. PHP errors could not be caught by PHP try/catch blocks, making it mandatory to use explicit checks for functions that could fail.
If your code needs to be compatible with PHP 5.6 or earlier, you can't use this convention. It may be worth experimenting with if you can mandate PHP 7.0 or later for your code, but I don't know what implications this may have for performance.
Try and catch by itself is truly quite expensive. Even when it is not used (i.e. no exception is generated), there is still some overhead that is "embedded" into the generated assembly. As for simple check whether the file exists and can be accessed, same thing happens: both of the things are system calls that are generally even more expensive. You should, however, also consider that the read operation on a file is a system call as well.
Now the question is narrowed down to what is more expensive: 2 system calls or 1 syscall with the exception handling. My assumption here (which I am somewhat confident about) is that the latter will be more expensive in case where the exception is actually being thrown, but faster in other cases. Since you've indicated that there will, in most cases, be no problems with accessing the files, it may be the case that you "should" use the exceptions. It is easier to deal with errors and does make the code a little bit more pretty (although it is arguable).
A little bit more on the code side of things: it totally depends on what your framework looks like now and what you want it to look like. You can, in fact, create a class that will deal with all this stuff in any of the two ways and they both will look clean (if done properly) and easily maintainable. If, however, you don't feel like keeping it in a separate class (or a separate file\function\universe), I would go for the exception handling.
Finally, as said before, the exception handling will generally be faster in you case, but ask yourself a question: How much of a problem is it? Do you perform the operation once per page access or do you do it multiple times? Will the page be accessed often or just once a day? How much of an impact will this create compared to all the other pages\algorithms that you have. There is a good concept know as 90/10 rule: 90% of the code is executed 10% of the time and vice versa. If this particular code is in these 90%, you shouldn't even worry about the performance as your concern should be the other 10% of the code. (You can read more about this here)
And one more thing: as noted by duskwuff, whatever is written here holds for PHP version >= 7.0
I was wondering, I have a few functions in PHP that're not called every time but still are included in my files on each load. Does it still run the code even if your not calling the function at that time? The reason I'm asking, the codes in my function are expensive to run CPU wise and I don't call them every time and want to make sure if there not called they do not run the code within the function.
Thank you
In short, a function that isn't explicitly called does not run. However, here is a short what and why we use functions that I found.
A function is a "black box" that we've locked part of our program
into. The idea behind a function is that it compartmentalizes part of
the program, and in particular, that the code within the function has
some useful properties:
It performs some well-defined task, which will be useful to other
parts of the program.
It might be useful to other programs as well; that is, we might be
able to reuse it (and without having to rewrite it).
The rest of the program doesn't have to know the details of how the
function is implemented. This can make the rest of the program
easier to think about.
The function performs its task well. It may be written to do a
little more than is required by the first program that calls it,
with the anticipation that the calling program (or some other
program) may later need the extra functionality or improved
performance. (It's important that a finished function do its job
well, otherwise there might be a reluctance to call it, and it
therefore might not achieve the goal of reusability.)
By placing the code to perform the useful task into a function, and
simply calling the function in the other parts of the program where
the task must be performed, the rest of the program becomes clearer:
rather than having some large, complicated, difficult-to-understand
piece of code repeated wherever the task is being performed, we have
a single simple function call, and the name of the function reminds
us which task is being performed.
Since the rest of the program doesn't have to know the details of
how the function is implemented, the rest of the program doesn't
care if the function is reimplemented later, in some different way
(as long as it continues to perform its same task, of course!). This
means that one part of the program can be rewritten, to improve
performance or add a new feature (or simply to fix a bug), without
having to rewrite the rest of the program.
Functions are probably the most important weapon in our battle against
software complexity. You'll want to learn when it's appropriate to
break processing out into functions (and also when it's not), and how
to set up function interfaces to best achieve the qualities mentioned
above: reuseability, information hiding, clarity, and maintainability.
http://www.eskimo.com/~scs/cclass/notes/sx5.html
PHP defines two SPL exceptions for invalid keys:
OutOfRangeException: Exception thrown when an illegal index was requested. This represents errors that should be detected at compile time.
OutOfBoundsException: Exception thrown if a value is not a valid key. This represents errors that cannot be detected at compile time.
As PHP isn't a compiled language the distinction between compile-time and run-time seems strange and thus I am finding it hard to understand which exception to use when.
Currently my understanding is that one should throw...
... OutOfRangeException if the key is fundamentally and inherently malformed, e.g. if an array is passed as a key.
... OutOfBoundsException if the key is generally okay, but isn't in some boundaries, e.g. if 100 is passed but 50 is the maximum key.
Is that understanding correct?
While PHP doesn't have a classic "compile time" (or a compiler that do a lot of static checks for that matter) I'd treat "compile time" as "rather static stuff I did wrong when writing the code" and "run time" as "my logic, input or validation was off at some point".
So my suggestion would be to treat it like this:
"Compile Time" / "OutOfRangeException": The error can always be fixed in the source code without or with very little logic.
I always take numbers from 1-10 and you put in 11
"Run Time" / "OutOfBoundsException": The error is due to wrong use at runtime.
You created me and told me to take values from 1 to 5 then you put in 7. Doesn't compute
or
You request an index that is not there because you didn't put it there like you should
Sample:
I'd expect an SplFixedArray to throw an OutOfBoundsException because it's size is dynamic and can chance at runtime while I'd expect something like a Calender::getMonthName to throw and OutOfRangeException because the number of month are definitely fixed at "compile/write" time.
Array object sample:
Say $array is an object that implements ArrayAccess you could throw an OutOfBoundsException in these circumstances:
$array['bar'];
$array[7];
As the values are what you could expect for ArrayAccess but it doesn't make sense in the case of an SplFixedArray(5). Alternatives would be DomainException or maybe RangeException
An OutOfRangeException in these cases:
$calendar->getMonth(15);
As putting an array or a new class there is definitely some bigger logic flaw in the code that usually results from a simple "oh, i put in the wrong variable" error by a programmer. An (maybe preferable) alternative would be UnexpectedValueException and good old InvalidArgumentException.
For cases like:
$array[array()];
$array[new StdClass];
some of the alternative exceptions seem more fitting.
Comparisons with the Java world on which exception to use when are not always applicable as Java Developers have an additions issue to deal with.
Checked/Unchecked exceptions. With many people arguing that everything that isn't a runtime exception has very limited use in Java / should not be used much internally) those names have lost some of their original meaning and intent.
My own take on this is:
LogicException
use for any mistakes the developer did, e.g. mistakes when programming/assembling the application. Those will hopefully be catched when the developer is running his/her UnitTests (which would then be the equivalent of Compile Time). Those exceptions should never occur on the production site as they are errors in the software as such.
RuntimeException:
use for any mistakes the user did or that result from invalid data put in the application at runtime. These are errors that might be anticipatable but not fully preventable by UnitTests, e.g. those can happen on a production site. Those exceptions could be stemming from incorrect usage or programming errors.
OutOfBounds
is IMO effectively what Wikipedia defines as Range of an Array in Range in Computer Programming, namely:
When an array is numerically indexed, its range is the upper and lower bound of the array. Depending on the environment, a warning, a fatal error, or unpredictable behavior will occur if the program attempts to access an array element that is outside the range.
In other words, when you have an array with indices [0,1,2] anything but [0,1,2] is out of bounds. Note that Bounds can also apply to other data types as well, e.g. trying to access the 7th character in a 5 character string would also be OutOfBounds.
OutOfRange:
this one is a tough cookie. In C++ OutOfRange is a generic exception extending LogicException (just like in PHP). I am not sure if the example given is easily translatable to PHP code though or my definition of Compile time above. Mainly because no one would first init a new Vector(10) and the immediately try to access it at(20).
In Java OutOfRange seems to refer to Range in the mathematical sense
The range of a function is the possible y values of a function that result when we substitute all the possible x-values into the function.
One reference I could find has it extending RuntimeException though, so I guess looking into other languages wont help to solve this mystery. There is also an open bug report about the SPL Exceptions in general, stating that
OutOfRangeException (value is out of range) is LogicException, should be: RuntimeException
But if this is correct, then how is OutOfRange different from DomainException? And if your own definition is correct, then how is OutOfRange different from InvalidArgumentException?
To cut a long story short: I dont know what OutOfRangeException is supposed to be for.
The answer to your question is quite elusive to me also. However, here are some things to think about:
If an array is passed in when we are expecting a valid array key, we also have InvalidArgumentException because it is not the proper argument type.
We could also throw a DomainException because arrays are not in the domain for array keys.
In php, you generally can't detect types at compile time because of late static binding. They purposefully delay binding of variables to runtime.
How I handle this situation:
Throw an InvalidArgumentException if a variable is passed in to any function where it the argument is not the correct type. I still do this when working with arrays.
Throw an InvalidArgumentException if null was passed in when it shouldn't be. This one really could be a lot of things because null isn't typed. To keep error code checking simple, I simply stick with the invalid argument.
Throw OutOfBoundsException when an index is not in the correct range, just as you suggested.
Throw BadFunctionCallException if a user-supplied function as a parameter does not have the correct form. If your structure inside is an array, it makes sense that they could pass in a function to modify it, so this comes up occasionally.
Generally, I can use just these three exceptions to represent all errors that occur outside of special resources (Network and database connections would be special resources). The third one seems to have been cropping up more often, but primarily I've just dealt with the former two.
It is quite simple:
OutOfRange mean "Your requested key is not within the index of a set defined in code."
OutOfBounds means "Your requested key is not within the index of a set defined by loaded configuration."
The confusion in this case comes from a couple of factors. First, PHP is in fact compiled into bytecode. There are several execution environments where this compiled form persists in a relatively permanent form on the server. However, the OutOfRangeException/OutOfBoundsException issue is not about that, it's about a categorization error made by the people who documented these specific exception classes.
Since PHP is dynamically typed, it's often impossible to actually check ranges and even types at compile time. The manual states that OutOfRangeException should be raised at compile time and OutOfBoundsException should apply at runtime, which is an erroneous distinction to make in this context.
Both manual entries use unclear language of what an illegal index means, but looking at the usage of their parent classes gives some clues: LogicExceptions are extended by classes like DomainException, InvalidArgumentException, and LengthException, whereas Runtime exceptions are things such as UnexpectedValueException, OverflowException and UnderflowException. From this pattern one can infer that OutOfRangeException should probably be applied to illegal key types, and OutOfBoundsException should apply to index values that are of the correct type but are not within the bounds of their container.
There was some discussion on the PHP dev list about these categorizations being wrong, but the issue goes deeper than that. In practice, both exceptions can only actually be are raised at runtime. You can use the vagaries of the documentation to squeeze out a distinction between invalid key types and invalid index values, but at this point we're talking about a bug in the PHP documentation.
If you get an unexpected index. ie you expect a string but end up with an integer or vice versa. Then you should throw an UnexpectedValueException exception.
If you get a proper type of index but it doesn't exist. Then raise a warning (trigger_error) and proceed on. This is not expected to stop programming flow.
If you have an object that is iterable or supposed to be iterated over a range and it reaches it's limit (ie the end of a file), then you should throw an OutOfBoundsException.
Anything else is a candidate for OutOfRangeException.
In layman's terms. An OutOfBoundsException is something normal. It's not that serious. It's something that happens often and should be taken care of. it can be used by iterators to keep reading data till there is no more to read. It is a logical error. Made by someone using the code not by someone writing the code.
An OutOfRangeException is something serious. Someone should look at the source code. Someone should find out what happened. This is important. Theoretically this was never supposed to happen. Call 911. It is a compile time error. Made by the dummy programmer.
Out of range exceptions are written by programmers to guard against mistakes by other programmers. Or maybe yourself in the future. If you feel like something like that could never happen then use Out Of Range. Use Out of Bounds for something likely to happen.
For instance:
// somefile.php
function doSomething() {
// do lots of code, whatever...
return $something;
}
// mainfile.php
include "somefile.php"
doSomething(); // ignored the return value, we don't need it here
What happens when a function in PHP returns a value but we don't care about it? Is something wrong with this behavior or should we always get the variable even if we'll never used it outside the function scope? How does PHP manage it's resources by returning a value that won't be used outside of the function scope?
The return value is discarded. There is nothing wrong with doing that. Even functions without an explicit return do return null implicitly:
function foo() {}
var_dump(foo()); // NULL
For me it all bowls down to a simple paradigm:
“A function should do one thing. It should do it well. It should do it only.”
If you have more than one reason to call that function is does to much.
From a language standpoint there is absolutely no problem with disregarding return values. From a clean code standpoint there is.
A insert() function should insert a record in a database. Not return the id of the inserted record. You didn't ask for that.
A setLatitude() should modify the objects internal state not load your Timezone class and figure in which timezone that latitude is and them write that to the database. (Saving the object can do that).
If you have two reasons to call a function it serves more than one purpose and from a clean code point of view it therefore: "Does too much"
Surely there can be cases constructed where it can make sense but as a general rule of thumb disregarding return values can be a code smell.
It's code smell, every time you return something which is not going to be used means you don't have an idea about your audience - you might be missing some other concept.
Also, such functions usually suffer from Command Query separation.
Few examples:
array_unshift(&$arr, $value, ...) prepends passed values to array and returns new size of array, how often do you want that information? and if you do, you can always call count($array) which was designed for this purpose.
sort(&$arr) sorts passed array and returns if it was successful. does it make sense? when something wrong happened you should know, exception should be raised/error triggered, do you really want to test success all the time? and do you?
print_r() is uber-example of this, it returns true(always so it's useless anyway) or string, depending on arguments you pass into it. this is definitely not how api should look like.
One possible exception could be fluent interface, like jQuery but that is VERY specific case.
HINT: Write few tests and rethink your architecture, if it really doesn't make sense in any other way, it's probably good enough. But you should always be careful in such situations.
There's nothing wrong with it. If you have a function that returns a value but also changes the program's state in some way (what's called a side effect), calling the function but ignoring the return value will simply cause all the side effects to be applied. You will, of course, not be able to use the return value if you don't store it, but sometimes all you want is the side effects of a call.
There are some people that believe in designing APIs in such a way that functions called for their side effects (commands) and functions called to observe some state of the program (queries) are separated as much as possible. This principle is called Command-Query Separation. The idea is that all functions that return something should not modify the program's state because they are observing it, and the act of observation should not affect the state observed. All functions that do not return anything are then seen as commands, called exclusively for their side effects.
People who follow these principles might therefore think that since your function clearly applies a side effect (or why would you call it and not care about the return value?), it should not observe any state (have a return value). Note, however, that this principle is not meant to always be followed to the letter, and there's also no huge agreement on it.
Why do some advocate command-query separation? Because it ensures that consecutive queries return the same answer if no command has been applied between the queries. It's sort of a weaker form of immutability, and carries a weakened form of the advantages that immutability can have for reasoning about the logic of a program. When applied consistently, objects are immutable in between commands.
In my view, keeping this principle in mind often results in less confusing APIs and clearer program logic, but it should not be carried too far. There are times when you may need to apply a side effect and return a value. When the return value is just a success value, however, consider raising an exception on failure instead.
The return is simply a means of passing a variable from within the function to be used outside of the function. The variables within the function are destroyed unless they have been set to static. In order to retain this value you would assign a variable to store it.
It is very common for code to have no need for a return variable. The fact that there is no need for a return variable does not mean that there is no use for a return variable.
Even though allowing a return of a function or method to die off has no ill effects, it is generally a bad practice. When a developer creates a return, it has a reason. This reason can be a number of things, such as: the effect of the function may have no result other than the return (this example isn't likely to fall in to your case), the returned result may be a reference for sequential operations, the returned result may be for debugging.
I recommend you find the intent for the return result and handle it accordingly. Often times ignoring a return result can potentially introduce an unpredictable state in your application that could have been prevented.
For instance, array_walk(). It handles your array by reference, there is no need to store the return variable for standard execution assuming everything goes well; however, if it fails, you have no way of knowing and your application may fail or give unexpected results if you automatically assume that it did not fail. If you would have collected that return variable and saw that it was false, you could have raised an exception, attempted to find out why and try again, or log the exception for future reference.