FAQ
I published a (work in progress) RFC today about replacing certain
errors with exceptions. I know that there already was something similiar
on the php6dev blog, but this is not completly the same, so awating your
comments:

http://wiki.php.net/rfc/errors_as_exceptions

Search Discussions

  • Troels knak-nielsen at Jul 24, 2009 at 1:37 pm

    On Fri, Jul 24, 2009 at 3:23 PM, wrote:
    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something similiar
    on the php6dev blog, but this is not completly the same, so awating your
    comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    Maybe I'm missing the point somewhere, but isn't this as simple as
    installing an error-handler with set_error_handler? You can install a
    global handler, that throws ErrorException, if you want that.

    The example mentioned in the rfc - simplexml_load_file - is a bit
    special. If you load an invalid file, you may get more than one error.
    If these were converted into exceptions, you would miss all but the
    first.
    user@domain.invalid
    whois

    --
    troels
  • Kalle Sommer Nielsen at Jul 24, 2009 at 1:40 pm

    2009/7/24 <user@domain.invalid>:
    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something similiar
    on the php6dev blog, but this is not completly the same, so awating your
    comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    I'm a big -1, I don't see a big reason for wrapping all my code in a
    try/catch block when im writing flat out procedural for example, PHP
    isn't an OO-only language, if you need to catch such errors via
    exceptions you can simply do it by having a custom error handler and
    the ErrorException as you linked to, like:

    set_error_handler(function($severity, $message, $file = NULL, $line =
    NULL, $context = NULL)
    {
    if(!(error_reporting() & $severity))
    {
    return;
    }

    throw new ErrorException($message, 0, $severity, $file, $line,
    $context);
    });

    I don't know if PHP should adopt code into the core that can be done
    in less than 10 lines, however with an ini setting it might work as
    long its off by default, but I'm not sure how many others here are
    happy about adding another ini setting for this.


    ps. Fix your email when posting


    --
    regrads,

    Kalle Sommer Nielsen
    kalle@php.net
  • Ben Scholzen 'DASPRiD' at Jul 24, 2009 at 1:43 pm
    To you both, this is especially, for library code like Zend Framework.
    The library cannot expect the user to have the error handle set, so it
    would have to replace the error handler before every line which it wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.

    Kalle Sommer Nielsen schrieb:
    2009/7/24 <user@domain.invalid>:
    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something similiar
    on the php6dev blog, but this is not completly the same, so awating your
    comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    I'm a big -1, I don't see a big reason for wrapping all my code in a
    try/catch block when im writing flat out procedural for example, PHP
    isn't an OO-only language, if you need to catch such errors via
    exceptions you can simply do it by having a custom error handler and
    the ErrorException as you linked to, like:

    set_error_handler(function($severity, $message, $file = NULL, $line =
    NULL, $context = NULL)
    {
    if(!(error_reporting() & $severity))
    {
    return;
    }

    throw new ErrorException($message, 0, $severity, $file, $line,
    $context);
    });

    I don't know if PHP should adopt code into the core that can be done
    in less than 10 lines, however with an ini setting it might work as
    long its off by default, but I'm not sure how many others here are
    happy about adding another ini setting for this.


    ps. Fix your email when posting

    --
    ...................................
    : ___ _ ___ ___ ___ _ ___ :
    : | \ /_\ / __| _ \ _ (_) \ :
    : | |) / _ \\__ \ _/ / | |) | :
    : |___/_/:\_\___/_| |_|_\_|___/ :
    :........:........................:
    : Web : http://www.dasprids.de :
    : E-mail : mail@dasprids.de :
    : Jabber : jabber@dasprids.de :
    : ICQ : 105677955 :
    :........:........................:
  • Kalle Sommer Nielsen at Jul 24, 2009 at 1:54 pm
    Please don't top post

    2009/7/24 Ben Scholzen 'DASPRiD' <mail@dasprids.de>:
    To you both, this is especially, for library code like Zend Framework.
    The library cannot expect the user to have the error handle set, so it
    would have to replace the error handler before every line which it wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.
    Then ZF should provide an error handler that can be called inside the
    user's error handler or simply choose to not use error handlers if the
    user have a custom error handler. I can't really see why the whole
    language should change into using exceptions by default because of
    something like this?


    --
    regrads,

    Kalle Sommer Nielsen
    kalle@php.net
  • Ben Scholzen 'DASPRiD' at Jul 24, 2009 at 2:07 pm

    Kalle Sommer Nielsen wrote:
    Then ZF should provide an error handler that can be called inside the
    user's error handler or simply choose to not use error handlers if the
    user have a custom error handler. I can't really see why the whole
    language should change into using exceptions by default because of
    something like this?
    This second suggested solution doesn't change the current behaviour at
    all, just adds an additional one, which under usual circumstances will
    never appear.

    Again, say for example, you have the following code:

    - ------------------------------
    $fp = @fopen(...);
    if (!$fp) {
    // !some! error occured, handle it
    }
    - ------------------------------

    I already described the problems with this in the RFC, e.g. you don't
    know, which error occurded, just that fopen failed. What a library
    currently would have to do is:

    - ------------------------------
    function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
    }
    set_error_handler('exception_error_handler');

    try {
    $fp = fopen(…);
    } catch (ErrorException $e) {
    // Handle the exception
    }

    restore_error_handler();
    - ------------------------------

    One could surely do that, yet it is not only unneccesary much additional
    code, but also introduces overhead by setting and restoring the error
    handler again and again.
  • Lukas Kahwe Smith at Jul 24, 2009 at 2:27 pm

    On 24.07.2009, at 16:06, Ben Scholzen 'DASPRiD' wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Kalle Sommer Nielsen wrote:
    Then ZF should provide an error handler that can be called inside the
    user's error handler or simply choose to not use error handlers if
    the
    user have a custom error handler. I can't really see why the whole
    language should change into using exceptions by default because of
    something like this?
    This second suggested solution doesn't change the current behaviour at
    all, just adds an additional one, which under usual circumstances will
    never appear.

    Again, say for example, you have the following code:

    - ------------------------------
    $fp = @fopen(...);
    if (!$fp) {
    // !some! error occured, handle it
    }
    - ------------------------------

    I already described the problems with this in the RFC, e.g. you don't
    know, which error occurded, just that fopen failed. What a library
    currently would have to do is:

    - ------------------------------
    function exception_error_handler($errno, $errstr, $errfile,
    $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
    }
    set_error_handler('exception_error_handler');

    try {
    $fp = fopen(…);
    } catch (ErrorException $e) {
    // Handle the exception
    }

    restore_error_handler();
    - ------------------------------

    One could surely do that, yet it is not only unneccesary much
    additional
    code, but also introduces overhead by setting and restoring the error
    handler again and again.

    Well this RFC suggests using Exceptions as a solution to a well known
    problem:
    In many places you cannot really handle different error conditions
    well, because you cannot differentiate between different error
    conditions (did that include fail because of a parse error or because
    the file is missing?) or because you are passing data to a function
    who's job is to validate and handle the data (simplexml example).

    Currently the only solution is to enable track errors and the shut up
    operator. Obviously that sucks.

    Generally we have decided to leave Exceptions out of core with a few
    "exceptions":
    1) errors in the constructor will throw an exception
    2) extensions may choose to offer an Exception mode (see PDO)

    I never understood why we did 1), if a constructor can fail, then a
    factory should be used instead. But oh well. With 2) you are obviously
    also opening a pandoras box, that is similar to using a global error
    handler that turns all Notices, Warnings etc as Exception: you can
    easily break code that calls various libraries .. take for example
    passing in a PDO instance to one library which expects the normal
    error mode and another one that enables the Exception mode. For the
    most part however we can conclude that most libraries enable the
    Exception mode in PDO and I think you will be hard pressed to find any
    PDO code example that doesn't assume that the Exception mode is enabled.

    So does that mean its time to open the flood gates? Contrary to what
    the RFC states, Exceptions are not the one error handling mechanism to
    rule them all. They should be used for exceptional cases, but for the
    most part functions/methods do fine with just returning false. Thats
    all people need to know most of the time.

    The issue is when there isn't just one possible error condition but
    many and as a result you want to do different things based on which
    ever error condition occurred. So lets take the include example.
    Obviously when using include, you accept the case that the file is
    missing (is not readable .. not quite the same, but probably the same
    for the purpose of this example), otherwise require would have been
    used. So returning false in that case makes sense. However and here we
    do not have an answer yet, what should be returned when the file
    exists but has a parse error? This I would call an exceptional case,
    but are these cases sufficiently relevant so that we should force
    Exceptions upon our general userbase?

    One alternative approach would be to ensure that there are simply
    proper validation functions, that take the guess work out of the error
    condition. Like for ages people have been asking to make file_exists()
    able to work with the include path. In the same vain, a method for
    validating an xml file could be provided. The issue is here of course
    that in both of these examples, doing the validation incurs
    significant overhead (more so in the xml case), so doing the
    validation beforehand would adversely affect performance (nevermind
    the possibility of race conditions further complicating things). So
    one approach would be to use the shut up operator and only call the
    validation method afterwards to determine the exact cause of the issue.

    Anyways, just pondering .. I do not really have a good solution, just
    trying to define the problem at hand a bit more and the some of
    options on the table.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Hannes Magnusson at Jul 24, 2009 at 2:29 pm

    On Fri, Jul 24, 2009 at 15:43, Ben Scholzen 'DASPRiD'wrote:
    To you both, this is especially, for library code like Zend Framework.
    The library cannot expect the user to have the error handle set, so it
    would have to replace the error handler before every line which it wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.
    Why do you have to replace it?
    You RFC says you want to throw exceptions for all E_WARNINGs - thats
    exactly the same as *not* restoring it.
    Just register errorhandler for E_WARNING and thats it.

    The libxml extension already has functionality to suppress XML errors,
    so your simplexml_load_file() example is bogus.
    Better example is fopen() on network failures, but even then I don't
    understand the problem.


    -Hannes
  • Alexey Zakhlestin at Jul 24, 2009 at 2:35 pm

    On Fri, Jul 24, 2009 at 6:29 PM, Hannes Magnussonwrote:
    On Fri, Jul 24, 2009 at 15:43, Ben Scholzen 'DASPRiD'wrote:
    To you both, this is especially, for library code like Zend Framework.
    The library cannot expect the user to have the error handle set, so it
    would have to replace the error handler before every line which it wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.
    Why do you have to replace it?
    because in case of a library, there is a "third-party" called "user".
    User might have his own opinion on error-handlers. And then, there's
    even worse case, when there are 2 or three libraries mixed in the
    single project
    You RFC says you want to throw exceptions for all E_WARNINGs - thats
    exactly the same as *not* restoring it.
    Just register errorhandler for E_WARNING and thats it.

    The libxml extension already has functionality to suppress XML errors,
    so your simplexml_load_file() example is bogus.
    Better example is fopen() on network failures, but even then I don't
    understand the problem.


    -Hannes

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Alexey Zakhlestin
    http://www.milkfarmsoft.com/
    Sent from St Petersburg, Russian Federation
  • Hannes Magnusson at Jul 24, 2009 at 2:38 pm

    On Fri, Jul 24, 2009 at 16:35, Alexey Zakhlestinwrote:
    On Fri, Jul 24, 2009 at 6:29 PM, Hannes
    Magnussonwrote:
    On Fri, Jul 24, 2009 at 15:43, Ben Scholzen 'DASPRiD'wrote:
    To you both, this is especially, for library code like Zend Framework.
    The library cannot expect the user to have the error handle set, so it
    would have to replace the error handler before every line which it wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.
    Why do you have to replace it?
    because in case of a library, there is a "third-party" called "user".
    User might have his own opinion on error-handlers. And then, there's
    even worse case, when there are 2 or three libraries mixed in the
    single project
    No. The RFC says it should throw Exception. There is no need for other
    error handlers in that case.

    If you want multiple error handlers then create RFC for error handler stacking.


    -Hannes
  • Richard Lynch at Jul 27, 2009 at 3:12 am

    On Fri, July 24, 2009 9:35 am, Alexey Zakhlestin wrote:
    On Fri, Jul 24, 2009 at 6:29 PM, Hannes
    Magnussonwrote:
    On Fri, Jul 24, 2009 at 15:43, Ben Scholzen
    'DASPRiD'wrote:
    To you both, this is especially, for library code like Zend
    Framework.
    The library cannot expect the user to have the error handle set, so
    it
    would have to replace the error handler before every line which it
    wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.
    Why do you have to replace it?
    because in case of a library, there is a "third-party" called "user".
    User might have his own opinion on error-handlers. And then, there's
    even worse case, when there are 2 or three libraries mixed in the
    single project
    Construct your error-handler to "stack" nicely and throw or
    trigger_error whatever would have happened without it.

    Then you need not unset/reset the silly thing.

    --
    Some people ask for gifts here.
    I just want you to buy an Indie CD for yourself:
    http://cdbaby.com/search/from/lynch
  • Brian Moon at Jul 24, 2009 at 3:51 pm

    On 7/24/09 6:43 AM, Ben Scholzen 'DASPRiD' wrote:
    To you both, this is especially, for library code like Zend Framework.
    This tends to invalidate your entire argument IMO. Changing the core
    language because something is hard in an external framework that only a
    small percentage of actual PHP developers use is not a a good reason.
    On 7/24/09 6:40 AM, Kalle Sommer Nielsen wrote:
    I'm a big -1, I don't see a big reason for wrapping all my code in a
    try/catch block when im writing flat out procedural for example, PHP
    isn't an OO-only language
    ++1 on that.

    Brian.
  • Matt Wilson at Jul 24, 2009 at 4:00 pm
    I agree, however there are certain aspects of PHP's errors that leave
    a lot to be desired. For instance, a failed fopen or a failed socket
    will often result in an uncatchable warning from php. Sure, you can
    add a @ to the line but that's slow and doesn't tell you anything
    about what happened.

    I've been saying for years that PHP needs to get over its perl phobia
    and implement something like $!

    fopen("file", "r") or throw new Exception("Error: ". $!);

    Wouldn't that be nice?
    On Jul 24, 2009, at 10:51 AM, Brian Moon wrote:
    On 7/24/09 6:43 AM, Ben Scholzen 'DASPRiD' wrote:
    To you both, this is especially, for library code like Zend
    Framework.
    This tends to invalidate your entire argument IMO. Changing the
    core language because something is hard in an external framework
    that only a small percentage of actual PHP developers use is not a a
    good reason.
    On 7/24/09 6:40 AM, Kalle Sommer Nielsen wrote:
    I'm a big -1, I don't see a big reason for wrapping all my code in a
    try/catch block when im writing flat out procedural for example, PHP
    isn't an OO-only language
    ++1 on that.

    Brian.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Chris Stockton at Jul 24, 2009 at 4:32 pm
    Sorry for top post, on my android. I disagree that php has perl phobia, but
    I agree that a alternative to errors needs to be made. Your example is nice
    but might have some tricky implementation details if php continued to throw
    errors when it didn't detect $!. I.E. fopen(...) or throw new
    CustomException($!); when custom exception writes to a log file that also
    writes to $! Perhaps for file not found, For example, does the first fopen
    throw the error or supress it as the user likely wanted. However it becomes
    a moot point if errors are still thrown.

    On Jul 24, 2009 9:01 AM, "Matt Wilson" wrote:

    I agree, however there are certain aspects of PHP's errors that leave a lot
    to be desired. For instance, a failed fopen or a failed socket will often
    result in an uncatchable warning from php. Sure, you can add a @ to the line
    but that's slow and doesn't tell you anything about what happened.

    I've been saying for years that PHP needs to get over its perl phobia and
    implement something like $!

    fopen("file", "r") or throw new Exception("Error: ". $!);

    Wouldn't that be nice?

    On Jul 24, 2009, at 10:51 AM, Brian Moon wrote: > On 7/24/09 6:43 AM, Ben
    Scholzen 'DASPRiD' wrot...
  • Rasmus Lerdorf at Jul 24, 2009 at 5:23 pm

    Matt Wilson wrote:
    I agree, however there are certain aspects of PHP's errors that leave a
    lot to be desired. For instance, a failed fopen or a failed socket will
    often result in an uncatchable warning from php. Sure, you can add a @
    to the line but that's slow and doesn't tell you anything about what
    happened.

    I've been saying for years that PHP needs to get over its perl phobia
    and implement something like $!

    fopen("file", "r") or throw new Exception("Error: ". $!);

    Wouldn't that be nice?
    I don't see the big difference between that and:

    if(!fopen("file", "r")) throw new Exception();

    and error_get_last() gives you the type, error message, line number, and
    filename which you can access in your catch block. Presumably you still
    want to log these which you get for free so no need for the @.

    -Rasmus
  • Richard Lynch at Jul 27, 2009 at 2:52 am

    On Fri, July 24, 2009 11:00 am, Matt Wilson wrote:
    I agree, however there are certain aspects of PHP's errors that leave
    a lot to be desired. For instance, a failed fopen or a failed socket
    will often result in an uncatchable warning from php. Sure, you can
    add a @ to the line but that's slow and doesn't tell you anything
    about what happened.

    I've been saying for years that PHP needs to get over its perl phobia
    and implement something like $!

    fopen("file", "r") or throw new Exception("Error: ". $!);

    Wouldn't that be nice?
    No, it wouldn't.

    wtf is $! supposed to mean?!

    I don't want to know, actually.

    If I wanted to use a language that looks like a cat died on my
    keyboard, I'd just switch to perl.

    --
    Some people ask for gifts here.
    I just want you to buy an Indie CD for yourself:
    http://cdbaby.com/search/from/lynch
  • Richard Lynch at Jul 27, 2009 at 2:40 am

    On Fri, July 24, 2009 8:43 am, Ben Scholzen 'DASPRiD' wrote:
    To you both, this is especially, for library code like Zend Framework.
    The library cannot expect the user to have the error handle set, so it
    would have to replace the error handler before every line which it
    wants
    to try {} and reset it after the catch. This is not really a clean
    solution, at it can occur pretty often.
    If your library users can't set an error handler before loading Zend
    Framework, they have no business using Zend Framework. :-)

    I know for sure Exceptions aren't going into core PHP.

    Whether you can/should convince the simple_xml extension developer to
    convert or not, I dunno.

    --
    Some people ask for gifts here.
    I just want you to buy an Indie CD for yourself:
    http://cdbaby.com/search/from/lynch
  • Markus Fischer at Jul 24, 2009 at 5:44 pm
    Hello,

    user@domain.invalid wrote:
    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something similiar
    on the php6dev blog, but this is not completly the same, so awating your
    comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    One of the headlines reads "Proposal and Patch", but I can't find the patch?

    regards,
    - Markus
  • Alban at Jul 29, 2009 at 9:33 pm

    Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit :

    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something similiar
    on the php6dev blog, but this is not completly the same, so awating your
    comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    I'm agree for replacing error by exception. Even if this not a good idea,
    i think there is a big problem with error gesture into php.

    Exemple : http://fr3.php.net/manual/en/function.simplexml-load-string.php

    The simplexml_load_string documentation says :

    «
    Return Values

    Returns an object of class SimpleXMLElement with properties containing
    the data held within the xml document. On errors, it will return FALSE.
    »

    That's not true, on error, yes the fonction return false but
    simplexml_load_string return also an error on not xml formated string.

    The result is it's impossible to use this function without @ statement.

    This can be considered as a bug and change the documentation or remove
    the error in simplexml_load_string will fix the bug.
    In fact, with exception in place of error, the same problem had a simple
    solution with try / catch elements.

    Exception in place of error's make life easy for developpers because if
    developper want, he can do something by catching exception before the
    program interrupt.
  • Brian Moon at Jul 29, 2009 at 9:46 pm

    Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit :
    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something
    similiar on the php6dev blog, but this is not completly the same,
    so awating your comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    I'm agree for replacing error by exception. Even if this not a good
    idea, i think there is a big problem with error gesture into php.

    Exemple :
    http://fr3.php.net/manual/en/function.simplexml-load-string.php
    A couple of people have used SimpleXML as an example of how _PHP_ errors
    are broken. The only thing that makes SimpleXML nice is the utter
    horror that the other XML parsing extensions give you.

    SimpleXML error handling and behavior in general is confusing. So, if
    you want to have a discussion about how SimpleXML is messed up, have it.
    But, don't lump the whole language in with it.

    Brian.
    --------
    http://brian.moonspot.net/
  • Joey Smith at Jul 29, 2009 at 11:40 pm

    On Wed, Jul 29, 2009 at 05:33:18PM -0400, Alban wrote:
    The result is it's impossible to use this function without @ statement.
    SimpleXML is hardly alone here, but I would imagine that if we could identify
    these and get bugs opened on them, there'd be very little resistance to fixing
    that aspect.
  • Hannes Magnusson at Jul 30, 2009 at 8:48 am

    On Wed, Jul 29, 2009 at 23:33, Albanwrote:
    Le Fri, 24 Jul 2009 15:23:21 +0200, user a écrit :
    I published a (work in progress) RFC today about replacing certain
    errors with exceptions. I know that there already was something similiar
    on the php6dev blog, but this is not completly the same, so awating your
    comments:

    http://wiki.php.net/rfc/errors_as_exceptions
    I'm agree for replacing error by exception. Even if this not a good idea,
    i think there is a big problem with error gesture into php.

    Exemple : http://fr3.php.net/manual/en/function.simplexml-load-string.php [...]
    The result is it's impossible to use this function without @ statement.
    Are you intentionally ignoring what I've said previously in the thread?
    Please stop using SimpleXML as an example. You do not need @.
    <?php
    libxml_use_internal_errors(true);
    $sxe = simplexml_load_string("<?xml version='1.0'><broken><xml></broken>");
    if (!$sxe) {
    echo "Failed loading XML\n";
    foreach(libxml_get_errors() as $error) {
    echo "\t", $error->message;
    }
    }

    Outputs:
    Failed loading XML
    Blank needed here
    parsing XML declaration: '?>' expected
    Opening and ending tag mismatch: xml line 1 and broken
    Premature end of data in tag broken line 1

    No PHP warnings at all.


    Again. The examples you are looking for are network issues with
    fopen(), file_get_contents() and such things.

    -Hannes
  • Joey Smith at Jul 30, 2009 at 6:29 pm

    On Thu, Jul 30, 2009 at 10:48:49AM +0200, Hannes Magnusson wrote:
    No PHP warnings at all.


    Again. The examples you are looking for are network issues with
    fopen(), file_get_contents() and such things.

    -Hannes
    Hannes, these are actually the ones I had in mind when I sent my last
    email - unfortunately, it's been so long since I ran into one, I can't
    remember how to trigger it, which is why I suggested we get bugs filed.

    Conceptually, it doesn't seem like it should be that hard to fix them.

    However, now that it's come up, I'm wondering what the costs/risks are
    of setting libxml_use_internal_errors() on by default?
  • Hannes Magnusson at Jul 30, 2009 at 6:37 pm

    On Thu, Jul 30, 2009 at 20:28, Joey Smithwrote:
    However, now that it's come up, I'm wondering what the costs/risks are
    of setting libxml_use_internal_errors() on by default?
    I don't think thats a good idea.
    People are used to getting a warning when stuff fails, and suppressing
    them all of the sudden is not cool and people will waste a good chunk
    of time figuring out what is wrong with the script they are developing
    and eventually find out libxml_use_internal_errors() is enabled by
    default and they'll start flaming the list about how much we all suck.

    -Hannes
  • Markus Fischer at Jul 30, 2009 at 9:17 pm

    Hannes Magnusson wrote:
    On Thu, Jul 30, 2009 at 20:28, Joey Smithwrote:
    However, now that it's come up, I'm wondering what the costs/risks are
    of setting libxml_use_internal_errors() on by default?
    I don't think thats a good idea.
    People are used to getting a warning when stuff fails, and suppressing
    them all of the sudden is not cool and people will waste a good chunk
    of time figuring out what is wrong with the script they are developing
    and eventually find out libxml_use_internal_errors() is enabled by
    default and they'll start flaming the list about how much we all suck.
    Observing the thread, I totally agree to that. In my case I've "been
    there, done that" and although I flamed at the beginning why I can't
    catch the error properly (until I found the said function :) ), you can
    bring the counter example too: give no libxml_use_internal_errors() and
    throwing an exception instead, you don't have to worry about some
    special function to flip error handling. You just know how to cope with
    Exceptions, not some esoteric function to be called to get some
    information out.

    - Markus
  • Hannes Magnusson at Jul 31, 2009 at 9:35 am

    On Thu, Jul 30, 2009 at 23:17, Markus Fischerwrote:
    Hannes Magnusson wrote:
    On Thu, Jul 30, 2009 at 20:28, Joey Smithwrote:
    However, now that it's come up, I'm wondering what the costs/risks are
    of setting libxml_use_internal_errors() on by default?
    I don't think thats a good idea.
    People are used to getting a warning when stuff fails, and suppressing
    them all of the sudden is not cool and people will waste a good chunk
    of time figuring out what is wrong with the script they are developing
    and eventually find out libxml_use_internal_errors() is enabled by
    default and they'll start flaming the list about how much we all suck.
    Observing the thread, I totally agree to that. In my case I've "been
    there, done that" and although I flamed at the beginning why I can't
    catch the error properly (until I found the said function :) ), you can
    I just realized we don't link to that function from the simplexml docs.

    I'll add some "see also" links and add an "errors" section mentioning it too.

    -Hannes
  • Alban at Aug 3, 2009 at 4:14 pm

    Le Fri, 31 Jul 2009 11:35:45 +0200, Hannes Magnusson a écrit :

    I just realized we don't link to that function from the simplexml docs.

    I'll add some "see also" links and add an "errors" section mentioning it
    too.

    -Hannes
    Thank you for the documentation :)
  • Ben Scholzen 'DASPRiD' at Aug 5, 2009 at 4:46 pm

    Hannes Magnusson wrote on 31.07.2009 11:35:
    I'll add some "see also" links and add an "errors" section mentioning it too.

    -Hannes
    Same for XMLReader then, please.

    --
    ...................................
    : ___ _ ___ ___ ___ _ ___ :
    : | \ /_\ / __| _ \ _ (_) \ :
    : | |) / _ \\__ \ _/ / | |) | :
    : |___/_/:\_\___/_| |_|_\_|___/ :
    :........:........................:
    : Web : http://www.dasprids.de :
    : E-mail : mail@dasprids.de :
    : Jabber : jabber@dasprids.de :
    : ICQ : 105677955 :
    :........:........................:
  • Alban at Jul 31, 2009 at 12:16 am

    Le Thu, 30 Jul 2009 10:48:49 +0200, Hannes Magnusson a écrit :

    Are you intentionally ignoring what I've said previously in the thread?
    Please stop using SimpleXML as an example. You do not need @. <?php
    libxml_use_internal_errors(true);
    [...]

    Again. The examples you are looking for are network issues with fopen(),
    file_get_contents() and such things.

    -Hannes
    I'm sorry Hannes, you have right.
    I ignoring the existance of the "libxml" functions, and strangely, Pan
    didn't get the part of the thread where you talking about simplexml. So
    all my appologies :)
  • Ben Scholzen 'DASPRiD' at Aug 8, 2009 at 9:47 am

    Hannes Magnusson wrote on 30.07.2009 10:48:
    Are you intentionally ignoring what I've said previously in the thread?
    Please stop using SimpleXML as an example. You do not need @.
    <?php
    libxml_use_internal_errors(true);
    $sxe = simplexml_load_string("<?xml version='1.0'><broken><xml></broken>");
    if (!$sxe) {
    echo "Failed loading XML\n";
    foreach(libxml_get_errors() as $error) {
    echo "\t", $error->message;
    }
    }

    Outputs:
    Failed loading XML
    Blank needed here
    parsing XML declaration: '?>' expected
    Opening and ending tag mismatch: xml line 1 and broken
    Premature end of data in tag broken line 1

    No PHP warnings at all.


    Again. The examples you are looking for are network issues with
    fopen(), file_get_contents() and such things.
    I tested libxml_use_internal_errors() with XMLReader now, and it doesn't
    really work as intended. When calling $reader->read(), and reaching an
    invalid node, there is in fact the error stored in libxml_get_errors(),
    but PHP additionally still throws a "parse error" warning. When then
    trying to supress it there with @$reader->reader(), PHP doesn't throw
    the warning, but libxml also doesn't store the error internally. Passing
    libxml_noerror or libxml_nowarning to $reader->open() doesn't have any
    effect at all.
  • Greg Beaver at Aug 8, 2009 at 3:03 pm

    Ben Scholzen 'DASPRiD' wrote:

    I tested libxml_use_internal_errors() with XMLReader now, and it doesn't
    really work as intended. When calling $reader->read(), and reaching an
    invalid node, there is in fact the error stored in libxml_get_errors(),
    but PHP additionally still throws a "parse error" warning. When then
    trying to supress it there with @$reader->reader(), PHP doesn't throw
    the warning, but libxml also doesn't store the error internally. Passing
    libxml_noerror or libxml_nowarning to $reader->open() doesn't have any
    effect at all.
    http://bugs.php.net/report.php

    Greg

Related Discussions

People

Translate

site design / logo © 2021 Grokbase