Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86751
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.170 as permitted sender)
Message-ID: <5582F79C.7050804@gmail.com>
Date: Thu, 18 Jun 2015 09:53:48 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Kevin Bradwick <kevinbradwick@gmail.com>, internals@lists.php.net
References: <CAEB4dHKh4BKuT=kCyFiY9MN74Z2MhxWJrmHbGn0K1+h5Vdh=Qw@mail.gmail.com>
In-Reply-To: <CAEB4dHKh4BKuT=kCyFiY9MN74Z2MhxWJrmHbGn0K1+h5Vdh=Qw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC - making the Exception class abstract
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Too many times have I seen developers throwing Exceptions when what they
> really needed was something that gave it context like
> InvalidArgumentException or RuntimeException. Yes, I agree this is
> something to tackle at code review (and I do) but I feel PHP doesn't help
> the situation by making it an instantiatable class. I struggle to think of

Indeed, it doesn't - but PHP doesn't have to be helpful for 100% of
every use cases. It is plain impossible as some of them are in direct
contradiction. Example - one use case is yours, maintaining a code
standard in a project with strict guidelines. Another - making a
langugage that is easy to use to most unsophisticated user for quick
prototyping. Where concerns about strict exception hierarchy may be well
below concerns of developer convenience and productivity.
Thus, in one case you may not want to use Exception and in another
Exception may be all you need. The conflict can be resolved very easily
- leave Exception as is and introduce a policy using one of the
multitude of great code style tools available for the complex project.
IMO it's much better than creating a huge BC break that excludes one of
the use cases.
-- 
Stas Malyshev
smalyshev@gmail.com