Hello.
> Suppressing? You mean fataling. Suppressing implies ignore, which is the
> exact opposite of what I am proposing.
Yes, it seems I didn’t explain my thought clearly.
We have the following code:
```php
function some(): bool
{
return false;
}
function target(): void
{
if(some() === false) {
// error occurred, some logic if error
}
}
```
The point of this code is that we handle the error immediately at the
first level.
If we rewrite this using exceptions, it means we’ll be handling the
exception at the first level from where it was thrown.
> success return + error-return + the-world-is-broken
By "the-world-is-broken," does that mean "throw"?
And why is throw better than return? Why?
> Exceptions that are sometimes checked and sometimes not is Java, which is
> exactly why everyone hates Java's exception system.
That phrase can’t be considered an argument, because it’s unclear who
“everyone” is (I’m not part of that group), why they hate something,
and why we should care about their negative emotions.
Maybe they’re wrong?
Exceptions are a technique with both advantages and disadvantages.
For business-oriented languages, the advantages outweigh the
drawbacks, because there's less code.
Less code means fewer bugs.
Less code also means lower coupling, which makes refactoring cheaper.
Cheaper refactoring makes business development easier.
In programming, it’s often the case that something becomes trendy, and
old tools start getting hate just because some new-but-actually-old
approaches have appeared.
But in practice, trends fade, the fog clears, and proven methods keep
working. :)
> It's clear you do not support what I am proposing.
Why can’t I partially agree and partially disagree? The world isn’t
black and white.
I agree with the questions you raised — each of them is valid on its own.
But I think it’s worth reflecting on the implementation. And Occam’s
razor should be applied here.
Best Regards, Ed.
