how to generate qr code in asp.net using c# Error Handling in C#.NET

Generate QR Code in C#.NET Error Handling

A task can complete in one of three ways: it can run to completion, it can be canceled, or it can fault. The Task object s TaskStatus property reflects this through RanToComple tion, Canceled, and Faulted values, respectively, and if the task enters the Faulted state, its IsFaulted property also becomes true. A code-based task will enter the Faulted state if its method throws an exception. You can retrieve the exception information from the task s Exception property. This returns an AggregateException, which contains a list of exceptions in its InnerExceptions property. It s a list because certain task usage patterns can end up hitting multiple exceptions; for example, you might have multiple failing child tasks.

If you don t check the IsFaulted property and instead just attempt to proceed, either by calling Wait or by attempting to fetch the Result of a Task<TResult>, the Aggrega teException will be thrown back into your code. It s possible to write code that never looks for the exception. Example 16-17 starts two tasks, and since it ignores the Task objects returned by StartNew, it clearly never does anything more with the tasks. If they were children of another task that wouldn t matter if you ignore exceptions in child tasks they end up causing the parent task to fault. But these are not child tasks, so if exceptions occur during their execution, the program won t notice. However, the TPL tries hard to make sure you don t ignore such exceptions it uses a feature of the garbage collector called finalization to discover when a Task that faulted is about to be collected without your program ever having noticed the exception. When it detects this, it throws the AggregateException, which will cause your program to crash unless you ve configured your process to deal with unhandled exceptions. (The .NET Framework runs all finalizers on a dedicated thread, and it s this thread that the TPL throws the exception on.) The TaskScheduler class offers an UnobservedTaskException event that lets you customize the way these unhandled exceptions are dealt with. The upshot is that you should write error handling for any nonchild tasks that could throw. One way to do this is to provide a continuation specifically for error handling. The ContinueWith method takes an optional argument whose type is the TaskContinua tionOptions enumeration, which has an OnlyOnFaulted value you could use this to build a continuation that will run only when an unanticipated exception occurs. (Of course, unanticipated exceptions are always bad news because, by definition, you weren t expecting them and therefore have no idea what state your program is in. So you probably need to terminate the program, which is what would have happened anyway if you hadn t written any error handling. However, you do get to write errors to your logs, and perhaps make an emergency attempt to write out unsaved data somewhere in the hope of recovering it when the program restarts.) But in general, it s preferable to handle errors by putting normal try...catch blocks inside your code so that the exceptions never make it out into the TPL in the first place.

The final concurrency feature we re going to look at is data parallelism. This is where concurrency is driven by having lots of data items, rather than by explicitly creating numerous tasks or threads. It can be a simple approach to parallelism because you don t have to tell the .NET Framework anything about how you want it to split up the work. With tasks, the .NET Framework has no idea how many tasks you plan to create when you create the first one, but with data parallelism, it has the opportunity to see more of the problem before deciding how to spread the load across the available logical processors. So in some scenarios, it may be able to make more efficient use of the available resources.