> On Oct 24, 2019, at 12:31 PM, Rowan Tommins wrote:
>
> On Thu, 24 Oct 2019 at 16:38, Mike Schinkel wrote:
>
>>> Here, try() would swallow only FileException, other exceptions are still
>>> thrown. I'm not sure if this construct is worth introducing though, the
>>> difference compared to a pro
> On Oct 24, 2019, at 8:50 AM, Dik Takken wrote:
> However, you could also choose to leverage the new behavior of throwing
> exceptions to simplify your code. Passing the error condition to the
> caller can now be done by *not* handling the exception that is thrown, so:
>
> $filepath = __DIR__ .
On Thu, 24 Oct 2019 at 16:38, Mike Schinkel wrote:
> > Here, try() would swallow only FileException, other exceptions are still
> > thrown. I'm not sure if this construct is worth introducing though, the
> > difference compared to a proper try / catch is much smaller.
>
> I would want it to captu
> On Oct 24, 2019, at 8:05 AM, Dik Takken wrote:
> I fully agree. However I think the fear of having to add tons of try /
> catch to existing code is exaggerated. I use Python a lot, which
> quite an exception throwing machine in comparison. Still, my code is not
> cluttered with exception handli
On 21-10-19 19:56, Mike Schinkel wrote:
> The idea that functions that I could previously dealt with in four lines of
> code:
> $filepath = __DIR__ . '/foobar.json';
> if (false === ($content = file_get_contents($filepath)) ) {
>error_log( sprintf("failed to open '%s'", $filepath ));
>retu
On 21-10-19 19:19, Mark Randall wrote:
> On 21/10/2019 17:02, Rowan Tommins wrote:
>> - They immediately jump control out of the current frame of execution.
>> Unless you put a separate "try-catch" around every line, there is no
>> "acknowledge and run next line".
>
> I've been toying with the ide
On 21-10-19 18:02, Rowan Tommins wrote:
> There is no general way to know whether the result of aborting execution
> completely is better or worse than carrying on with unexpected values. In a
> program that's not expecting it, either one could lead to data loss or
> corruption.
I would guess that
On Tue, 22 Oct 2019 at 14:38, Benjamin Morel
wrote:
>
> I used this one function as an example, but I'm happy to apply my point of
> view to other examples if you wish.
>
You have phrased this as though your point of view is different from mine,
but I think you've just misunderstood it. I said:
@Mike,
> Then about a year ago I started using Go, and Go's approach to error
> handling just clicked for me. Go's philosophy is to handle the error as
> soon as you one is aware of it and to only ever handle it once. Since I
> have been using that strategy I have become very happy with my error
On 21/10/2019 21:38, Benjamin Morel wrote:
Sure, you can do without exceptions. I think what you're suggesting is
similar to Go's error handling. But PHP at some point decided in
favour of exceptions, so it would be logical to pursue in that direction.
I didn't say "do without exceptions", I
> On Oct 21, 2019, at 4:38 PM, Benjamin Morel wrote:
> Sure, you can do without exceptions. I think what you're suggesting is
> similar to Go's error handling.
Yes, it is like Go's error handling.
> But PHP at some point decided in favour of
> exceptions, so it would be logical to pursue in th
>
> I think this argument is something of a logical fallacy: just because
> exceptions are (or can be) more fine-grained than the current return
> value, that doesn't mean they're the best tool for the job.
> If I'm remembering it correctly, an example is the old PEAR
> error-handling model, where
On 21/10/2019 18:45, Benjamin Morel wrote:
I personally like exceptions in all cases, as they allow for
fine-grained error handling, for example:
```
try {
mkdir('somedir');
} catch (FileExistsException $e) {
// only catch *this* exception, which my program expects,
// let any other
> On Oct 21, 2019, at 5:10 AM, David Negrier
> wrote:
>
> Hey list,
>
> TL;DR:
>
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
JMTCW, which is an opinion admittedly probabl
> I agree with the distinction described by Nikita.
> There are definitely cases where a special return value is still the
> best option.
I personally like exceptions in all cases, as they allow for fine-grained
error handling, for example:
```
try {
mkdir('somedir');
} catch (FileExistsExc
I agree with the distinction described by Nikita.
There are definitely cases where a special return value is still the
best option.
In addition I would say in some cases it can be useful to have both
versions available: One that returns FALSE or NULL, another that
throws an exception.
This is for
On 21/10/2019 17:02, Rowan Tommins wrote:
- They immediately jump control out of the current frame of execution.
Unless you put a separate "try-catch" around every line, there is no
"acknowledge and run next line".
I've been toying with the idea of:
$x = tryval fopen('missing.txt', 'r'),
Hi David,
Firstly, I agree with Nikita's general rule of which Warnings should be
promoted and which need deeper thought.
I would like to challenge one assertion in your e-mail, which is related to
that thought process:
On Mon, 21 Oct 2019 at 14:52, David Negrier
wrote:
> We would be happy t
On Mon, Oct 21, 2019 at 3:52 PM David Negrier <
d.negr...@thecodingmachine.com> wrote:
> Hey list,
>
> TL;DR:
>
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
>
> The long versio
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
I would *LOVE* if these functions could be fixed, and if I had the almighty
merge button at my disposal, I'd press it whenever suc
On 21-10-19 11:10, David Negrier wrote:
> I'm considering writing an RFC (and a patch) to turn some warning into
> exceptions in a number of PHP functions.
> I would first like to gather some feedback here.
I think this is definitely worth a shot. My suggestion would be to split
the effort in sets
Hey list,
TL;DR:
I'm considering writing an RFC (and a patch) to turn some warning into
exceptions in a number of PHP functions.
I would first like to gather some feedback here.
The long version:
It is the first time I'm posting on internals.
Some of you may already know me. I'm one of the auth
22 matches
Mail list logo
