.
Are you looking for a try-catch statement?
try {
Stream dataStream = request.GetRequestStream ();
}
catch (WebException e) {
Debug.Log("Here is where you gracefully handle the exception that says "+e.Message);
}
Or, more generically, you could put try-catch around the entire process (if any potential failure of the process has the same kind of âgraceful failureâ), and use catch (Exception e) instead.
try-catch is super handy, maybe one of the best features of C#. I definitely recommend learning more about it!
Without any try-catch at all, the entire application would just crash when a runtime error occurs⌠and thatâs basically the situation in C++. (Iâm currently trying to debug a C++ DLL and it is hell) You literally have to code for every possible error condition, and in order to report it to code âupstreamâ, you have to make the function return an error code (rather than what you actually want to be returning).
try-catch makes all that obsolete: if a function has an error, it âthrowsâ an exception, which then just goes back up to whatever called that function⌠and up and up and up until something âcatchesâ that particular exception.
In all of the code that you write that is called by a Unity function (Start, Update, etc etc), it is always wrapped (on Unityâs side) in a try-catch that outputs the exceptionâs message to the Console, to act as a failsafe for the way most of us write most of our code - without that, a single script error would crash the Unity editor. With that, we can see what the error is and figure out how to fix it (or ignore it as we see fit).
Anyway, just trying to instill in you an appreciation for try-catch as a result of my recent workings in a language that doesnât have it. Enjoy!
Generally, any code thatâs dependent on the line(s) that may cause an exception are included in the âtryâ block along with it; the execution of that block will stop when it throws an exception so those lines wouldnât be run. So putting the dependent lines inside the try block is your if-then.
One thing to be aware of is that any exceptions of the same kind in the subsequent lines inside the try block, would also be caught. Most of the time this is a good thing (if any of the following lines fail, you probably want to respond in the same way), but you do have to be aware that it might leave things in a weird state. For example, if dataStream.Write throws a WebException, it may cause dataStream.Close() to not be called. I donât know what if any consequences might arise from that, itâs just something to consider. For this reason, you may wish to have some kind of cleanup after the try-catch (lines that will be executed whether an exception is thrown or not).
Of course, you also have to write the âcatchâ block, which is to say, you have to decide what happens when the request fails - that is, you need to decide how to fail gracefully. Put up an error message to the user? Try again in 5 seconds? Change to a different game mode? Thatâs where you do that.
You can certainly have a valid internet connection, but not be able to connect to your service. That is probably more likely to happen actually.
You can have an internet connection, but your server might be down. You need to check the return code of the web request to confirm, you would probably get a 404. Youâll want to test. If you get an error, then take the appropriate action. You first need to elaborate in English exactly what you want to happen if you get such an error, this is known as pseudo-code.
No, a 404 (Not Found) is a valid response from a web server, as is 403 (Access Denied). You can still have an internet connection, but your web server may be returning an error. OpenRead may return â403â, but thatâs not an exception. For a valid HTTP connection and a happy server, the response code should be 200/OK, you should check for that. I would encourage you to try yourself. Youâll need a public web server like on Amazon AWS. They have free tiers available that would get you started.
Google says âHttpWebResponse.StatusCode Property (System.Net) | Microsoft Learnâ