Viewed   84 times

I can't do something like this ?

try {
    require_once( '/includes/functions.php' );      
catch(Exception $e) {    
    echo "Message : " . $e->getMessage();
    echo "Code : " . $e->getCode();

No error is echoed, server returns 500.



You can do it with include_once or file_exists:

try {
    if (! @include_once( '/includes/functions.php' )) // @ - to suppress warnings, 
    // you can also use error_reporting function for the same purpose which may be a better option
        throw new Exception ('functions.php does not exist');
    // or 
    if (!file_exists('/includes/functions.php' ))
        throw new Exception ('functions.php does not exist');
        require_once('/includes/functions.php' ); 
catch(Exception $e) {    
    echo "Message : " . $e->getMessage();
    echo "Code : " . $e->getCode();
Saturday, October 22, 2022

Here's what worked best for me when trying to script this (in case anyone else comes across this like I did):

$ pecl -d php_suffix=5.6 install <package>
$ pecl uninstall -r <package>

$ pecl -d php_suffix=7.0 install <package>
$ pecl uninstall -r <package>

$ pecl -d php_suffix=7.1 install <package>
$ pecl uninstall -r <package>

The -d php_suffix=<version> piece allows you to set config values at run time vs pre-setting them with pecl config-set. The uninstall -r bit does not actually uninstall it (from the docs):

[email protected]:~$ pecl help uninstall
pecl uninstall [options] [channel/]<package> ...
Uninstalls one or more PEAR packages.  More than one package may be
specified at once.  Prefix with channel name to uninstall from a
channel not in your default channel (

  -r, --register-only
        do not remove files, only register the packages as not installed

The uninstall line is necessary otherwise installing it will remove any previously installed version, even if it was for a different PHP version (ex: Installing an extension for PHP 7.0 would remove the 5.6 version if the package was still registered as installed).

Monday, December 12, 2022

This appears to be a bug in GCC's implementation of copy elision. The C++ standard says the following:

[class.copy.elision] (emphasis mine)

This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):

  • in a throw-expression, when the operand is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object can be omitted by constructing the automatic object directly into the exception object

In the following copy-initialization contexts, a move operation might be used instead of a copy operation:

  • if the operand of a throw-expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one),

This is a family of optimizations that allows the copy initialization of an exception object to be either avoided or done as efficiently as possible. Now, a common implementation of std::string move construction is to leave the source string empty. This appears to be exactly what happens to your code. The temp in the outer scope is moved from (and left empty).

But that is not the intended behavior. The scope of the temp you throw exceeds (by far) the try block it's thrown in. So GCC has no business applying copy elision to it.

A possible workaround is to place the declaration of temp inside the while loop. This initialized a new std::string object every iteration, so even if GCC moves from it, it won't be noticeable.

Another workaround was mentioned in the comments and is to make the outer temp a const object. This will force a copy (since a move operation requires a non-const source object).

Tuesday, November 8, 2022

The catch-clause _ -> ... only catches exceptions of the 'throw' class. To catch other kinds of exceptions, you need to write a pattern on the form Class:Term -> ... (i.e., the default Class is throw). In your case:

  _:_ -> {"Error! Json is invalid", ReqData, Context}

When you do this, you should always ask yourself why you're catching every possible exception. If it's because you're calling third-party code that you don't know how it might behave, it's usually OK. If you're calling your own code, remember that you're basically throwing away all information about the failure, possibly making debugging a lot more difficult. If you can narrow it down to catching only particular expected cases and let any other exceptions fall through (so you see where the real failure occurred), then do so.

Tuesday, August 23, 2022

Never used any of those, but they look interesting..

Take a look at Gearman as well.. more overhead in systems like these but you get other cool stuff :) Guess it depends on your needs ..

Friday, November 11, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :