Datagrid Page Index Exception

Permutations of this bug appear to occur when paging is used and viewstate is turned on in the datagrid. Seemingly random exceptions occur with this error string:
Invalid CurrentPageIndex value. It must be >= 0 and < the PageCount

Because of viewstate, the grid tries to remember where it was the last time the page was posted. If the postback returns less paged data than the previous page, this exception will be thrown. Consider a datagrid with enough data to fill 4 pages. The user navigates to page four, clicks a button which causes a postback. This time around, the data isn�t sufficient to fill four pages, but rather 3 pages are returned. During the render phase, the grid will attempt to navigate to page 4. There is no page 4. An exception is thrown because the currentpageindex 4 must be greater than or equal to 0 and less than the page count 3.
�

There are three approaches to fix this problem.
��������
When you bind in your page event handler simply set the currentpageindex = 0. This guarantees that the index is always within the correct bounds. If there is no data returned the data grid is not displayed. The down side is that the user is always returned to page 0 on the returned data � not an overly heavy price to pay for application stability.�
�
Allow the error to occur and then catch the exception�in a try block resetting the index to 0 and rebinding the grid
try
{
����� //bind code
}
catch(ArgumentOutOfRangeException)
{
�datagrid1.currentpageindex = 0;
������� //re-bind code
}

This is a modification of item 1. The catch block fires and incurs a performance penalty only when the exception is thrown.
�����
Turn off viewstate. Turning off viewstate implies that the control will no longer be able to maintain its state. The onus is on the programmer to write code to maintain this state and re-hook events.

Is�this a bug? I argue that it is not. The run-time cannot uncover the programmer�s intent when this condition is met. It cannot assume that the last page in the collection is what is intended so it shouldn�t navigate to the last page returned. This assumption would not hold true for every condition. For example if you were on page 100, and 50 pages of data were returned for a new request, it is flawed logic to forcibly navigate the user to page 50 or page 1. All the grid assumes is that you want to be back on page 100 on the returned data. This assumption is based on viewstate. If that page is not there, then the run-time correctly assumes that there is an error or ambiguity in the programmer�s logic and promptly throws an argumentoutofrange exception.
�
Let�s put this discussion into a philosophical light. A teacher instructs you to open your text book to page 35. You open up the text book and discover that there are 25 pages. Is this your fault? If it is, then it is bug. If it is not, and the fault lies with the teacher then she has created an ambiguous situation. What should you do? Inform her that there is an ambiguous situation? Open up the book to the first page? I believe the run-time makes the correct assumption by indicating that there is an ambiguous condition by promptly throwing a nasty exception.
�

Microsoft corporation and/or its respective suppliers make no representations about the suitability, reliability, or accuracy of the information and related graphics contained herein. All such information and related graphics are provided "as is" without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information and related graphics, including all implied warranties and conditions of merchantability, fitness for a particular purpose, workmanlike effort, title and non-infringement. You specifically agree that in no event shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental, special, consequential damages or any damages whatsoever including, without limitation, damages for loss of use, data or profits, arising out of or in any way connected with the use of or inability to use the information and related graphics contained herein, whether based on contract, tort, negligence, strict liability or otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of damages.