I do prefer the shorter name.��Generally I avoid using exception as a suffix consistently if doesn't add information.��
> On 08 Sep 2016, at 09:03, Guille Polito <guillermopolito@gmail.com> 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> 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
>>
>
>