The most frustrating thing on earth

You know what's the most frustrating thing on earth? Writing code for design time databinding. If you've never tried it, and want to feel how frustration can flow throw a human body, please give it a try. If you're lucky you'll do everything right the first time, but as the documentation lacks and the code to write isn't that simple, you probably will make a few mistakes here and there. But that's not that bad, right? You have exceptions with stacktraces and debuggers, right?

Well... no. You could setup VS.NET to debug you design-time code, however that's a cumbersome experience at best. Best of all: if in your debugging session an exception is thrown somewhere in your own code, the debugger won't stop there, as it does with every other managed application run in the debugger. No, instead the exception will bubble up to VS.NET and two things can happen there:

  • The IDE crashes. (Happens to me on VS.NET 2005 on a regular basis)
  • You'll get a message like "Object reference not set to an instance of an object" or "Specified argument was out of the range of valid values. Parameter name: Index was out of range. Must be non-negative and less than the size of the collection" or similar. No stacktrace. That's right, no stacktrace.

Now, if your code is small, you could possibly place a breakpoint in every routine you have, but if your code is rather large, like 100,000+ lines of code and a lot of classes are involved, you're in serious trouble. Where did that lovely exception originate? If you would have a stacktrace, it would have been simple: check the stacktrace, place a breakpoint there and see what happens. After all, that's normal debugging procedure.

Not with design time databinding code and VS.NET. Stacktraces are considered a thing only stupids would use apparently and therefore not provided. I can tell you from experience, if you have to fix a problem which pops up an error originating somewhere in a .NET class but you have absolutely no clue where it originates from, it is frustrating, and then I'm putting it lightly.

Who decided to strip off a stacktrace in an exception! The same stupidity is present on the compact framework for .NET 1.x: "So, hotshot-developer, you want to bind a collection of objects to that grid in your mobile application, huh? Well, an error occured somewhere in the code you wrote and referenced. Where, I won't tell you. I know where it originates, but let's play a little game: you look for the root-cause and I keep my mouth shut, like it? No? Well, I don't care, deal with it. Back to stone-age gdb debugging style, baby!".

If you've never dealt with this kind of code, consider yourself lucky, and consider yourself warned: if your manager walks into the room and asks you if it's possible to write some design time databinding supporting code for a set of controls you wrote, remember what you just read.

Happy coding, although this kind of crap sucks all the motivation out of me to say "Yes, VS.NET is a great IDE".

12 Comments

  • I totally agree with that.



    I also feel that using the databinding features of ASP.Net is incredibly difficult as well. There is hardly any way to debug anything when you make a mistake, you just get non informative error messages with no way to know where they came from. Quite frankly, I feel that these situations would be the paradigmatic argument for source code access to the framework classes. Of course, if the framework would always throw errors that are descriptive enough to understand what is happening, fine. But clearly it is not at this point.

  • Hi Frans,



    I can feal your pain and I do consider myself warned!

    :-)



    Would you consider this "feature" to be driving force for testing as much of the code as possible separately, with ordinary unit tests? Or am I on the wrong track?



    Best Regards,

    Jimmy

    www.jnsk.se/weblog/

    ###

  • I'd have to say the most frusterating thing on Earth would have to be considered a pretty large exageration. I can think of few things that are worse. Not to say that you are wrong. VS.Net can be quite annoying.



    "Object reference not set to an instance of an object" - This is by far the most common and annoying. You are right about the error messages being completely useless sometimes but they are still better then JSP, Perl and many other languages.

  • You could probably debug Visual Studio with another debugger (VS, WinDbg, etc) and catch the first chance exception. Haven't tried that though.



    I don't think "stacktraces are considered a thing only stupids would use," I spend a lot of time talking to people who don't seem to be aware that stack traces exist and can be used to debug problems.

  • So Debug.Asserts never displayed? Glancing through the Assert method via Reflector, I remember seeing something to allow you to register a handler for Asserts... so if theres no handler when running inside VS.Net, you could create your own that simply shows the normal MessageBox, although I cant imagine the code running in the VS process doesnt have an Assert handler.

  • Asserts aren't the solution as I get an exception, and I want the origin so I can check why the exception occurs. Of course, you can write a gazillion assert statements in your code, but that's not the point as you then still can miss an exception and at the same time can be very cumbersome to wade through all the messages in messageboxes.



  • Yes it's frustrating.



    I was helping refactor the exception handling code in a large app last year and one of my tricks was to run the app under the debugger and have it break whenever an exception is raised. This way you can check the call stack and find the cause.



    If you Ctrl-Alt-E in the IDE you get the Exception dialog in VS where you can adjust the filtering of which exceptions cause it to break.



    It is a bit of a pain - but it does help solve the problem.



  • Dude, you whine and bitch in almost every one of your posts lately. I used to think your you and your blog are cool but I'm tired of seeing these "this sucks", "this is broken", and "this doesn't work" entries. Instead of whinning, do you think you might be able to use your all-knowing intellect to help guide folks from going through the same pains you do in a constructive non-deragotry fashion? Seriously, it's getting old.



    Unsubscribed



    P.S. Implement a bloody ad-hoc design-time/ComponentModel host, it's not that difficult

  • "Instead of whinning, do you think you might be able to use your all-knowing intellect to help guide folks from going through the same pains you do in a constructive non-deragotry fashion? Seriously, it's getting old. "

    Oh dear.

    Apparently it is more appropriate to be part of MS' marketing department and solely hail&praise their stuff, ignore what's annoying and broken and don't tell anyone where the pitfalls are. Noo, that's whining and instead people should write the same old MSDN-doc rehashing tutorials , right?



    "Implement a bloody ad-hoc design-time/ComponentModel host, it's not that difficult"

    Ah, so I have to learn how to do that, write that, debug it, and then I have... a surrogate host for components like a form...



    Perhaps you don't know it, but my code should run with ANYONE's forms, not with my own surrogate host.



    So, instead of letting people and MS know what's frustrating and needs improvement, we should stick our head into the sand and hope for the best and spend another set of hours to write redundant code to work around a design canvas which falls apart.



    And you unsubscribed, that's your choice of course. I understand your time is better spend on blogs which just rehash what MS marketing wants us to write about. C'est la vie.

  • Oh and James, apparently you've missed my C# rotozoomer! Oh yeah, let's forget the positive articles and info :)

  • Any chance this frustration started with VS 2005? I'm seriously trying to remember when did I feel so frustrated while using VS 2003 and I can't remember one single chance. Yet I'd say frustration has been a constant since the first betas with VS 2005.



    They did add some nice features, but I'm talking about the general IDE experience, more of a phsycological point of view.

  • I haven't looked at objectviews yet, so I can't comment on it that well, but I think it works similar to other view-ish objects which tend to form a controller between the grid/control (viewer) and the object/collection (model). This can of course work OK, though it's a bit backwards (you normally bind the collection or a bindingsource and the collection gives back a view) but if it works as I think it works, it can be useful. Nevertheless, design time databinding is something that's not logical, not well documented and even with MS stuff it doesn't work well. (add a dataset with 2 tables to a form, add a bindingsource to a form, a datagrid view, bind the bindingsource to the grid, set the bindingsource datasource to the first table, you'll see columns of the first table. Then switch the datamember on the bindingsource frm none to the second table. Poof... 1 column shown in datagridview.

Comments have been disabled for this content.