Making things the hard way

[DerVVulfman]

I think the point you are trying to suggest is that software needs fixing after it is written, and that it is up to the end-users to report where the errors appear. However, it should be up to the software developer to ensure that no bugs appear, no fixes are needed, and no end-users have need to report bugs to the author. Of the third party, an end-user reporting bugs, I have been one to make countless bug reports to a fellow scripter, one that doesn't even test his own work.

Since when are safeguards meant to prevent one from learning how to perform a script call? I think that this notion against safeguards is ill conceived. As I pointed out juet a few hours ago, one could pass improper data into your first ruby terniary example and receive the phrase 'illegal' as a temporary safeguard of its own. Yes, it is helpful to receive pertinent data from the end user if an error appears, but it is up to you as the coder to ensure that no error exists. As to silly mistakes from an end user, it could be that the user erred in using the code. However, proper documentation which I know you loathe is vital. It too is one of the things that I was taught in regards of programming. Instructions should be concise and clear.

I do not argue that the raise system does not have its uses. I too use it for testing the validity of cached graphics. However, my usage of the raise command is to create a safeguard to prevent missing-file crashes. I do not expect nor desire that the end-user be burdened with errors and include the fact that such a feature is in place in these instances. And I would correct you that incorrect user behavior as you call it is based solely on improper instructions and not safeguards. Safeguards would have nothing to do with a user not following instructions, nor lack of proper instructions from the software creator.

I would actually suggest that any coder worth his salt should be able to test his or her own code, regardless of the code being a compiled language like C++ or an interpreted language such as Basic or Ruby. Division by zero is kind of a longshot. However, if a routine or method is put into place where the divisor eventually goes down to a zero value, a safeguard should be crafted to ensure no such error appears and the best-closest value is generated without the need of generating a raise error message. No such raise error message should even be needed. I would look to the programmer for failing to take the time to troubleshoot his own code if countless errors appear.