Untested return values.

[Kristian]

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*

(Thanks for pointing out the usage of exceptions in D, though.)


>> 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)?