Marc Chamberlin said the following on 02/11/2011 12:56 AM:
..... an editor that failed to properly warn a user about embedded non-printing characters, a parser somewhere in autofs that failed to properly warn a user about embedded non-printing characters in a configuration file, a mount process that failed to tell the user that it could not perform it's task because it encountered those same non-printing characters, ..... Well, you were using a GUI. The command line version has STDIN, STDOUT an STDERROR streams Applications do complain - to the STDERROR stream that has no counterpart when you are using a GUI.
Unless of course the GUI designer chooses to make the GUI very heavy and monitor all the error codes. But then perhaps the GUI designer chose not to write a wrapper around the CLI and instead, being a programmer, wrote it all in C, and found that checking all the return codes and interpreting the results and writing all the handlers and branching code was just too tedious and boring. o STDERROR messages can easily be directed to a log file and a GUI designer can easily make a user aware of that log file and point him to it. Or even open it up to him/her and display it for him/her. That is a far better approach than simply dropping them on the floor, which so easily can happen is using command lines... Marc, you say you are a programmer. Do you ALWAYS check the return codes when subroutine and procedures are called, do you ALWAYS write the branching code and handlers for the results for each and every one at each and every level? I tend to use OO design methodologies and design patterns to encapsulate error handling. I tend to design programs up front to handle error
By using the CLI and seeing the errors I learnt quickly. Which, as I have been trying to point out, is responding to error situations after the fact, and forcing the user to try and visualize what might have gone wrong that caused such an error. That requires a LOT of inside detailed knowledge, on the users part, in order to successfully grok a solution. Reverse your thinking when it comes to designing for usability and try to be more preemptive when designing a
On 2/11/2011 5:10 AM, Anton Aylward wrote: processing, not put it in as an afterthought. Allows for reusable components that way. Yeah there may be a performance hit, but with today's superfast processors, it usually is not a big factor. The main question I focus on is what in the heck is a user going to do should an error occur, and how am I, as a developer, going to guide him/her to a solution, or teach him/her why what he/she was trying to do, is wrong. Focusing on error handling design up front usually means I don't have to deal with each and every return code explicitly as I write code. I wrap those kind of things with an OO pattern and focus on other issues. program to be a guide for a user. Rather than just throw the error out to the user, which often is just about as useful as saying "I can't do that, and I can't help you Mr. User. Good Luck!", give him/her some options, or a simple explanation immediately and guide him/her. You may not get it right the first time you throw out your application for users to use, but if you have provided him/her with easy feedback capabilities, your application can grow and adjust quickly to handle the unforeseen events. With a good robust error handling mechanism in place, you probably will be lucky and be able to repair the damage much easier. If it was a learning issue, that is an opportunity for you to enhance your program as a teacher, so others won't fall into the same trap. Granted you have to gage, as a developer, what learning/functional problems most of your users are having, and focus on those first, no one is expecting an application to get it right the first time, but just having the ability to let your users provide you with feedback easily, WILL advance your program far faster than the current methods of using external documentation and difficult to find bug trackers, forums etc., allow. You can do all this with CLI also, but it requires some careful thinking about how you will achieve most of these usability goals. You have less tools to use to interface with your users, but it probably is doable in most situations where CLI makes sense. .
Of course you could have monitored the various files in /var/log Of course I look in /var/log! Don't insult my intelligence. I found nothing helpful, why do you think I came onto this forum to ask for help in the first place?
Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org