De : nicolas.gre...@gmail.com [mailto:nicolas.gre...@gmail.com
Envoyé : vendredi 24 août 2012 09:24
1) PHP Errors come with a severity code and a string message. You
want
to handle specific errors in a specific way? You better start writing
giant regexes parsing the string messages.
On Fri, 3 Aug 2012, Ferenc Kovacs wrote:
Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into
**
The overall mood seems to be that since PHP has an error handler, everyone
is free to handle errors any way they want.
2) When everyone starts handling errors in their own way with error
handlers, you can't reliably use third party code. You are in your own
universe.
I think that's the
2012/8/24 Nicolas Grekas nicolas.grekas+...@gmail.com:
**
The overall mood seems to be that since PHP has an error handler, everyone
is free to handle errors any way they want.
2) When everyone starts handling errors in their own way with error
handlers, you can't reliably use third party
The overall mood seems to be that since PHP has an error handler, everyone is
free to handle errors any way they want.
Everyone is surprisingly ignoring the two giant holes in that theory:
1) PHP Errors come with a severity code and a string message. You want to
handle specific errors in a
Hi!
Have you stopped for a moment to think this opinion through? Look at two
Of course not. Why would I bother thinking? It is always safe to assume
nobody thinks before writing anything to the list.
typical patterns of error handling. The examples below are generalized from
my file cache
You are either purposefully exaggerating or not doing it right.
if(fileop1() fileop2() fileop3()) {
// do valid stuff
} else {
// do error stuff
}
It's not that hard.
I guess it was my mistake that I simplified my actual code for simplicity's
sake. Please show me how would my actual code
I know PHP's model is all messed up, but no one here, I believe, is
asking about putting non-error log messages in Exceptions. IO failure is
an exception.
If your IO operation fails, you can't just log it and plow forward
blissfully without handling the problem.
Stan
Exceptions allow
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
Have you stopped
errors, you can't just fread the return value. You *need* to change your
execution flow based on that error. Therefore, it is exceptional.
That's exactly what I am saying. Exceptions should not be a means of
flow control, and that's exactly what are you doing here.
I agree that exceptions
Stas,
On Tue, Aug 7, 2012 at 1:46 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
circumstance. If it's not, you should be checking for existence first
(via file_exists() or is_readable(), etc)...
This is exactly how we got into this mess with $x =
isset($a['x'])?$a['x']:null;
We're
2012/8/6 Stas Malyshev smalys...@sugarcrm.com
Exceptions are different from PHP errors. For example, if you try to
open a file and the file isn't there, throwing exception is a very
annoying behavior (yes I know some languages do that, IMO it's wrong).
The reason is that it's pretty normal
On 06/08/12 08:43, Amaury Bouchard wrote:
2012/8/6 Stas Malyshev smalys...@sugarcrm.com
Exceptions are different from PHP errors. For example, if you try to
open a file and the file isn't there, throwing exception is a very
annoying behavior (yes I know some languages do that, IMO it's wrong).
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
This type of thing
Hi!
but sometimes you want to be more precise. With exceptions, we have an
elegant way to manage all failures as a whole, or to differenciate each
reason.
You do not, unless you have 20 exception types and catch them all
separately. Which nobody would ever do for one simple reason - what if
Hi!
Personally, I'm used to what other languages like Python do, and I think
it makes more sense. Exceptions mean you can try/catch the things your
code needs to be prepared for (non-existence, maybe), but other things
No, they mean you need to *always* try/catch since you have to means to
On 06/08/12 19:48, Stas Malyshev wrote:
Hi!
Personally, I'm used to what other languages like Python do, and I think
it makes more sense. Exceptions mean you can try/catch the things your
code needs to be prepared for (non-existence, maybe), but other things
No, they mean you need to *always*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 06.08.2012 20:44, schrieb Stas Malyshev:
Hi!
but sometimes you want to be more precise. With exceptions, we
have an elegant way to manage all failures as a whole, or to
differenciate each reason.
You do not, unless you have 20 exception
Hi all,
Am 06.08.2012 20:41, schrieb Stas Malyshev:
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
This type of thing is
Levi et al:
On Mon, Aug 6, 2012 at 8:55 PM, Levi Morrison morrison.l...@gmail.comwrote:
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again,
Hi!
circumstance. If it's not, you should be checking for existence first
(via file_exists() or is_readable(), etc)...
This is exactly how we got into this mess with $x =
isset($a['x'])?$a['x']:null;
We're trying to get out of this mess and you're proposing to build
another mess just like
Hi,
having worked on the user land side of error handling
[1]https://github.com/nicolas-grekas/Patchwork-Logger/blob/master/class/Patchwork/PHP/ErrorHandler.php,
I wanted to share some more ideas that could help enhance the current error
handling mechanism.
Concerning throwing vs not throwing
Hi!
Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but
. . .For example, if you try to
open a file and the file isn't there, throwing exception is a very
annoying behavior (yes I know some languages do that, IMO it's wrong).
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
This type of
Hi,
We started a discussion about the current error handling mechanism and the
possible improvements in the Why do disabled functions / classes generate
a WARNING thread[1], but that is a little bit offtopic there, so I decided
to create a separate thread for it.
Basically Etienne mentioned that
On Fri, Aug 3, 2012 at 10:55 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
We started a discussion about the current error handling mechanism and the
possible improvements in the Why do disabled functions / classes generate
a WARNING thread[1], but that is a little bit offtopic there, so I
When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo.
My choice isn't based as much on what the current error severity is, or what
the error severity is supposed to represent in general, because I've found
in PHP often the error severity has no connection with the error
On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass sv_for...@fmethod.com wrote:
When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo.
My choice isn't based as much on what the current error severity is, or
what the error severity is supposed to represent in general, because I've
On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass sv_for...@fmethod.com wrote:
When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo.
My choice isn't based as much on what the current error severity is, or what
the error severity is supposed to represent in general, because
On Sat, Aug 4, 2012 at 1:44 AM, Stan Vass sv_for...@fmethod.com wrote:
**
On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass sv_for...@fmethod.com wrote:
When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a
typo. My choice isn't based as much on what the current error severity is,
if we turn E_STRICT to behave exactly as E_ERROR there is no point keeping
the E_STRICT level.
personally I disagree with turning something which was a pedantic notice in
one version into an unsupported feature which fatals out if you try to use it
in the next.
maybe
32 matches
Mail list logo
