Exception Handling - How it work?

Unity Engine
1

Hello,

Sorry for my question, but i’m learning C# programming. I have a question, how and for what i use Exception Handling? I see a lot of tutorials on MSDN and another websites, but i can’t understand it. Suggest me any tutorial please.

Thanks.

2

Here is the msdn article:

I’ll also give my own simple explanation as follows, and frame it in the context of Unity.

a function can throw an exception:

public void SomeFunct(object obj)
{
     if(obj == null) throw new System.ArgumentNullException("obj");

     //do stuff as long as the obj wasn't null
}

This exception basically states that some operation failed due to some critical issue. In the case of this example, this function REQUIRES the parameter ‘obj’ to not be null, it throws an exception if it is.

Many of the built in .Net/Mono classes throw exceptions for various reasons. Say you access an array at an index out of range, you get an IndexOutOfRangeException.

These exceptions are supposed to represent a problem in operation of code that otherwise couldn’t have been determined at compile time. Usually it’s something that is variable in nature, so it only can occur at runtime.

These exceptions are all class types themselves. They inherit from the base exception class type ‘System.Exception’. This unique class type allows you to distinguish exceptions apart.

You can implement your own custom exception type by inheriting from System.Exception (or any other exception).

The documentation for a function will usually include the list of exceptions that may occur if you call it improperly, and why.

If an exception occurs, and the exception is not handled. Operation haults, and the application faults, and may even close. In the case of a Unity application, all unhandled exceptions that occur on the main thread are usually caught by the unity engine itself and logged as warnings. The code following that exception no longer operates, but unity will continue chugging on to the next frame of code, where the same code that threw may or may not throw the exception again. You’ll see this in the console if so.

With that in mind, and you know you have a chance of calling a function, and it failing… you can wrap that call in a ‘try/catch’ like so:

try
{
     SomeFunctThatCanThrowAnException(someParameter);
}
catch (System.Exception ex)
{
     //react to the exception
}

In this case, if ‘SomeFunctThatCanThrowAnException’ throws an exception, then operation doesn’t hault. Instead operation immediately jumps to the ‘catch’ line, and code in there operates. You can then clean up your state as a result and act accordingly.

Say a function throw 3 different exceptions though. You can catch just the type of exception you want. This is the point of the unique class types for each exception. You can even handle for multiple exceptions.

try
{
    var v = someArray[index];
    v.Foo(someParam);
}
catch (System.IndexOutOfRangeException ex)
{
    //react to if the index was out of the range of the array
}
catch (System.NullReferenceException ex)
{
     //react if 'v' was a null value when we attempted to call Foo
}
catch (System.ArgumentNullException ex)
{
     //react if 'Foo' threw an exception because someParam was a null value passed in, and 'Foo' doesn't like null values for 'someParam'
}
finally
{
     //code to operate no matter what after all is said and done, even if an exception didn't occur
}

Of course, you usually avoid calling a function that may throw an exception if you’re in a state that would cause it to throw one. For instance you wouldn’t bother accessing the value in an array if the array was empty.

if(someArray.Length >= index)
{
    //index is out of range, so do something
}
else
{
    var v = someArray[index];
    if(v != null) v.Foo(someParam);
}

But some things just don’t have a way to anticipate if an exception will be thrown.

For example say you create a socket connection with a remote client. And during operation the socket connection fails and disconnects and data is lost. You could not anticipate that ahead of time, because it’s not a fault with your code, but instead a fault with the network connection between client and you. So an exception throws informing you. So most network connection code will be wrapped in a try catch in case it fails.

6 Likes