I do prefer the shorter name. Generally I avoid using exception as a suffix consistently if doesn't add information. Consistency is overrated :D On Thursday, 8 September 2016, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 08 Sep 2016, at 09:03, Guille Polito <guillermopolito@gmail.com <javascript:;>> wrote:
I'd argue also for consistency. When some exceptions are named "Exception" and others are not, my eyes hurt.
+1
-------- Original Message --------
My very first thoughts are...
On Thu, Sep 8, 2016 at 3:35 AM, stepharo <stepharo@free.fr
<javascript:;>> wrote:
Hi guys
in https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and- FileDoesNotExistException sven proposed to have
FileDoesNotExist and remove the FileDoesNotExistException This seems quite reasonable. It would be very hard to confuse the semantics of FileDoesNotExist with something else. Also this is probably something end-user-devs will use more frequently in their application, so less verbose is better.
The only thing that crosses my mind is perhaps discoverability... in Spotter searching on "File" the drilling into classes and searching on "Exception". Oh I just tried in Pharo 5 and it worked, there are four. The other way to handle that might be for Spotter to have a "KindOf" search.
btw, in the Spotter preview pane when a class is selected, could the class comment be displayed?
Before doing it I would like to have your point of view on the names. For now I'm neutral and indeed if we apply it to exception
it seems to work for announcement. Now in Spec I was planning to put nearly systematically Presenter at the end of Presenters :). Spec has more interrelated design pattern components. Its seems there has been some confusion around the nomenclature of these components. So the additional hint is probably beneficial.
cheers -ben