GUI's make it hard to figure out what went wrong.

If I am going to complain about GUI's, it makes sense for me to probably come up with something better. The better UI would perhaps include the best of GUI, a little bit of file editing (code like) and a search feature beyond anything we now have. The search feature would be based on endemes and focused as its context on the application at hand. Anyway, here is this week's rant about GUIs.

Lets say you use the SQL Server Reporting Services Report Designer to build a report, then store it in SharePoint, then run it from either SharePoint or a C# program. Most of this is handled with GUI's. If something goes wrong, you get the useless message 'An error has occurred during report processing. (rsProcessingAborted) Query execution failed for dataset 'MyList'. (rsErrorExecutingCommand) For more information about this error navigate to the report server on the local server machine, or enable remote errors '. How do you tell where the error is? Is it in Sharepoint? SQL Server? Your Stored Procedure? Your Dataset? Your Report? The way the connection is stored in SharePoint? Your C# program? The browser? Because none of these systems allow you to use breakpoints you can't tell which failed. In this case it turned out to be permissions on my stored procedure. It could just as easily have been any of the others; but the error doesn't say anything about permissions problems. It doesn't say anything about a stored procedure. And yes I've tried enabling remote errors and it has never worked.

Another error I have had complains about not being able to connect to the database. How was I to know it was some checkbox or other in SharePoint? The error mentioned the database, not SharePoint.
--
Why don't GUI's have debuggers? Even if you can't change the code inside, seeing where things go wrong could be really helpful. We who build user interfaces can do this.

MORE...