Safe way of Windows Phone Tasks handling

Have you ever wondered how you should use Windows Phone 7 Tasks correctly? When you look through the examples on MSDN, in most cases you will find following structure:

Task task = new Task();
try
{
  task.PropertyA = "A";
  task.PropertyB = "B";
  task.PropertyC = "C";

  task.Show();
}
catch (System.InvalidOperationException ex)
{
  MessageBox.Show("An error occurred.");
}

Sometimes you can find opinion that an exception handling is not required. From my point of view this is not correct.

using Microsoft.Phone.Tasks;
…
SmsComposeTask smsComposeTask = new SmsComposeTask();

smsComposeTask.To = "2065550123";
smsComposeTask.Body = "Try this new application. It's great!";

smsComposeTask.Show();

The problem occurs when you want to find out why InvalidOperationExcepion is being thrown. MSDN does not provide any information about this issue. You can try to look for in whole Task class and method Show() documentation, but you will not find anything.

So far I have managed to find three scenarios in which an InvalidOperationExcepion is being thrown:
[list]

method Show() is being executed several times before first call will be finished. We will get following exception message: Not allowed to call Show() multiple times before a Chooser returns. This situation occurs quite often. User have to click more than one time the button which will execute the Task. In many cases developers do not test such scenario. Occurrence of this error will cause closing of the application.
method Show() is being executed when a navigation is in progress. We will get following exception message: Not allowed to call Show() when a navigation is in progress. To reproduce this error please use steps described in the first point.
the last scenario is very closely associated with the previous ones. To invoke errors you need to start Task several times, e.g. by double tapping on button that will start the Task. In this case you will get the following exception message: Navigation is not allowed when the task is not in the foreground.

[/list]
As you can see all of those situation are caused by the same user behaviour. The type of exception message is determined by the moment you press the button that will execute Task.

Due to the fact that, all scenarios are in most cases caused by incorrect user action you can found very often the proposal that you should simply ignore InvalidOperationException when it occurs:

Task task = new Task();
try
{
  task.PropertyA = "A";
  task.PropertyB = "B";
  task.PropertyC = "C";

  task.Show();
}
catch (System.InvalidOperationException ex)
{
}

In most cases I agree with the proposed suggestion, but only when I am sure about the correctness of implemented solution. Please note that the described errors can be caused not only by unusual behaviour of the user, but also by errors in implementation, e.g. when developer will start navigation to other page and right after execute Show() method.

I have left the most important case for the end. Show() method can throw also exception of type ArgumentOutOfRangeException. Unfortunate, the MSDN does not provide any information about it. Moreover you will not find any interesting information in Google. You will find only one result when you will use exception message – The size of input should not exceed 64K – as a search query in Google.

This type of exception is being thrown very rare. You could even say almost never. This type of exception will be thrown only when the parameters passed to the Task after serialization will take more than 65536 bytes. In most cases it is simply unbelievable. But there are some Tasks where this situation is possible and you should be aware of it. An example of that Task we can use EmailComposeTask. If only the message you want to send will be long enough, that exception will occur.

Summarizing, each software developer should be aware of how developed application is working and which exceptions can be thrown. Support for unusually situations should be adjusted for expected scenarios that can cause an error. What is the most important you should not assume that user will behave rationally. And the last thing you can do is error tracing in AppHub. You should respond on each error as quickly as it is possible.