RE: [PHP-DEV] Error handling brainstorming

> 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 messa

Re: [PHP-DEV] Error handling brainstorming

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

Re: [PHP-DEV] Error handling brainstorming

2012/8/24 Nicolas Grekas : >> ** >> 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

Re: [PHP-DEV] Error handling brainstorming

> ** > 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'

Re: [PHP-DEV] Error handling brainstorming

> 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 > Exception

Re: [PHP-DEV] Error handling brainstorming

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 cod

Re: [PHP-DEV] Error handling brainstorming

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 cach

Re: [PHP-DEV] Error handling brainstorming

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 spec

Re: [PHP-DEV] Error handling brainstorming

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 fo

Re: [PHP-DEV] Error handling brainstorming

Stas, On Tue, Aug 7, 2012 at 1:46 AM, Stas Malyshev wrote: > 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 ge

Re: [PHP-DEV] Error handling brainstorming

>> 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 excepti

Re: [PHP-DEV] Error handling brainstorming

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 th

Re: [PHP-DEV] Error handling brainstorming

Levi et al: On Mon, Aug 6, 2012 at 8:55 PM, Levi Morrison wrote: > >> 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 ever

Re: [PHP-DEV] Error handling brainstorming

>> 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 o

Re: [PHP-DEV] Error handling brainstorming

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 e

Re: [PHP-DEV] Error handling brainstorming

-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 exc

Re: [PHP-DEV] Error handling brainstorming

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*

Re: [PHP-DEV] Error handling brainstorming

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

Re: [PHP-DEV] Error handling brainstorming

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

Re: [PHP-DEV] Error handling brainstorming

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 thin

Re: [PHP-DEV] Error handling brainstorming

On 06/08/12 08:43, Amaury Bouchard wrote: 2012/8/6 Stas Malyshev 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'

Re: [PHP-DEV] Error handling brainstorming

2012/8/6 Stas Malyshev > 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 and within normal set

Re: [PHP-DEV] Error handling brainstorming

> . . .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 o

Re: [PHP-DEV] Error handling brainstorming

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,

Re: [PHP-DEV] Error handling brainstorming

Hi, having worked on the user land side of error handling [1], I wanted to share some more ideas that could help enhance the current error handling mechanism. Concerning throwing vs not throwing e

Re: [PHP-DEV] Error handling brainstorming

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 E_STRICT->E_DEPRECAT

Re: [PHP-DEV] Error handling brainstorming

On Sat, Aug 4, 2012 at 1:44 AM, Stan Vass wrote: > ** > > > On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass 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 su

Re: [PHP-DEV] Error handling brainstorming

On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass 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 found in PHP oft

Re: [PHP-DEV] Error handling brainstorming

On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass 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 > found in PHP often

Re: [PHP-DEV] Error handling brainstorming

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 that

Re: [PHP-DEV] Error handling brainstorming

On Fri, Aug 3, 2012 at 10:55 PM, Ferenc Kovacs 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 decided > to