Let's talk about clean code and exception handling.
So this use case that I've got prepared for you is very common across beginner developers.
You know, when you develop desktop applications or back end applications for web development where
you open up files on a server, for example, you're dealing with the System.io namespace almost every
time opening up streams, opening up files like here, file, read all text, and so on.
There is so much what could go wrong under the hood.
The file path could be wrong.
The file does not exist.
The file is not readable.
You do not have the permissions to actually read the data.
The data that you want to read is corrupt and so on.
Right there.
There's so much what could go wrong.
So this is a great example to talk about exception handling.
The ultimate goal for sure is that the end user who is using your software is not facing crashes.
The app should never crash.
The app should never just hang up and freeze or show a big red like, uh, pop up box that says like
that app has crashed and needs to get restarted or what?
You know, you should always show some toast notifications or pop ups that say, hey, something's gone
wrong.
The file was not able to be found, or the access is unauthorized or whatever.
However, here we got such a situation, the chances are really high that if you submit the file path,
something goes wrong, especially if the end user himself writes down the path.
He could simply forget to add a forward, a hyphen or whatever character, so therefore it totally makes
sense to add some try catch here.
You know how it's done.
We have covered that in a previous section of the course, so we simply wrap the code that could cause
issues into a try block.
This is our file read probably the Console.WriteLine will not cause any errors if content here will
be read.
So this line of code will cause the exceptions if something goes wrong.
And then we think about okay, what could go wrong and what would be the best message for the user.
It's not a good practice or a good clean code way to simply throw any message at the user and say something
has gone wrong, right?
Goodbye.
No, you want to be as descriptive as possible so that the user understands what's going on, or that
another developer who's using your code and faces, uh, exception also understands.
Okay, what was exactly the problem?
I do understand that something has gone wrong, but what was the problem?
If you are a C-sharp developer for quite some time, probably you have faced error messages or exceptions
where you wished that there would be more description inside.
So let's be that kind of developer.
Let's add different exceptions for the most common use cases for our reach all text.
For example, here, when we read a file, we could run it to a file, not found exception, unauthorized
exception, or basically anything else but file not found and unauthorized access would be the most
common ones.
Let's add a catch block here.
Let's catch the file not found exception.
If we have any, let's call it x and then we simply c w file not found.
We exactly tell the user what has gone wrong and then we add the exception message.
Right.
Let's just duplicate that paste it back in.
You can wrap it around just like this.
Do the same for the unauthorized access unauthorized access exception here.
Here we do not say file not found.
Instead we say access denied so the user knows what has gone wrong.
And then finally we catch any other exception.
So we can say exception X for example.
And then we simply Console.WriteLine.
More generic message.
Now an error occurred and then we simply add the x message here.
So hopefully you got the point.
We catch the exceptions so that the program does not crash right for the end user.
And for another developer that uses your code or your software.
Right.
And we provide descriptive messages that help the user, for example, to understand what was causing
the issue so that he knows how to solve the problem.
That would be a great example of when to use exceptions.
But as I said, if you are writing an algorithm that simply cannot crash, you don't want to wrap this
inside of a try catch block, right?
Only wrap it inside of try catch blocks if it makes sense, and if it's common that the user or another
developer will cause exceptions here, for example.
For fi reading, but also for web communication.
For example, if you send HTTP requests, if you want to build a connection to a database and all of
that, because that really depends on other factors.
For example, is the database accessible?
Is the web server online, is the file existing?
And so much more.
So we got many external variables here that could cause our algorithm to run into an error and to throw
exceptions.
And that's the perfect moment when you want to use try and catch.