Untested return values.

[Lionello Lunesu]

Kristian wrote:
> On Thu, 05 Oct 2006 14:45:42 +0300, Lionello Lunesu 
> <lio at lunesu.remove.com> wrote:
>> Kristian wrote:
> [snip]
>> If you don't care whether the file got deleted, why do you delete it 
>> in the first place? OK, I know very well what you're trying to say and 
>> I do it myself all the time, but I'll also admit that it's sloppy 
>> programming.
>>
>> Furthermore, 'the D way' is to throw an exception, not to return some 
>> value that is or is not tested.
>>
>> By the way, do you often use
>>
>> try { /* some code*/ } catch (Object o) {/* no code*/}
>>
>> too? They should, since the same reasoning applies to function 
>> throwing an exception.
> 
> Ok, ok, maybe my 'eraseFile()' example wasn't the best one... :)
> 
> I can't resist (sorry) pointing out that sometimes it's ok to silently 
> ignore errors. ;) For example, there is a program that creates a 
> temporary file. When the program is exited, the file will be deleted. 
> Now, if the file cannot be deleted for some reason, what could you do? 
> Notify the user with a message box telling that "Cannot delete the XXX 
> file." or "Please delete the XXX file, or else!..." (that would annoy 
> me, at least), or silently accept the fact that the file cannot be 
> deleted and exit the program? *grin*

Like I said: point taken :)

>>> Clearly you wouldn't want to do any extra work when calling functions 
>>> of the group A. Or have warning/error messages with them. However, 
>>> with the group B that would be ok.
>>
>> Granted, so perhaps it could be a warning message after all. 
>> Definately not an error, we've established that.
> 
> A warning message with an ability to turn it off? Or as I would prefer, 
> a warning with an ability turn it on (it's off by default)?

In D, warnings are off by default. You explicitly ask for warnings using -w.

L.