[Mono-bugs] [Bug 78417][Nor] Changed - RepeaterItemCollection null reference exception

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by grendello at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78417

--- shadow/78417	2006-05-16 12:23:34.000000000 -0400
+++ shadow/78417.tmp.28585	2006-05-16 17:23:47.000000000 -0400
@@ -25,6 +25,29 @@
 Created an attachment (id=17037)
 RepeaterItemCollection.cs.diff
 
 
 ------- Additional Comments From gonzalo at ximian.com  2006-05-16 12:23 -------
 Can you also attach a test case?
+
+------- Additional Comments From grendello at gmail.com  2006-05-16 17:23 -------
+It turns out that the whole problem got triggerred by my mistake. I've
+got a user control (in an .ascx with a code-behind file) which hosts
+two repeaters, one nested within the other. The inner repeater is data
+bound for each item of the outer one, from within the ItemDataBound
+event handler. Now, my mistake was that I wasn't binding the data to
+the outer repeater on page postback. This resulted in a backtrace like:
+
+Failed to get the contents of the products list control
+System.NullReferenceException: Object reference not set to an instance
+of an object
+in [0x00001] (at
+/usr/src/tmp/mono/mcs/class/System.Web/System.Web.UI.WebControls/RepeaterItemCollection.cs:62)
+System.Web.UI.
+WebControls.RepeaterItemCollection:get_Count ()
+
+which was due to the fact that ArrayList l was null in
+RepeaterItemCollection. The attached files show that happening.
+Despite my mistake of not binding the data, I do think that
+RepeaterItemCollection should be resistant to that kind of coding
+errors and therefore it should make sure l is never null.
+