Hello.
In this video, we will talk about Question 13, why cut exceptions, almost always a bad idea.
And when it is not touching an object of system exception type.
So the most general type of exceptions in C-sharp is almost always considered a bad idea.
This is because when you cut an exception, you should handle it appropriately.
But if you don't know what the exception type is exactly, how can you know how to handle it?
Let's consider this method.
It works similar to the parameters first or default method from LINK.
It returns the first month from the collection, but if the collection is empty, it returns the default
value in the cut gross.
We cut an exception and we print the information that the collection is empty.
But other exceptions not related to the emptiness of the collection can be thrown in the thread close
like out of memory exception or Stack Overflow exception for those two types.
It's extremely hard to predict when they will happen.
Of course, in a healthy application, they shouldn't happen at all.
But we don't know how the rest of this application looks like.
It might be the case that the cut close will cut out of memory exception, and it will handle it with
the false message saying that the collection is empty, even if it wasn't.
The true problem?
The lack of memory in the application would be swept under the rug.
Because of that, we should always catch a specific exceptions as possible.
The first method that we use here draws invalid operation exception when the collection is empty, so
handling this exception here is most appropriate for the same reasons.
We should always throw us specific exceptions as possible from our own code.
Let's consider this method.
Throwing an exception here is not a good idea.
We should be more precise when choosing an exceptional type, so it fits the situation when the first
exception is strong.
The problem lies with the new collection passed to the average method.
So are humans.
No exception is a perfect fit.
In the second case, when the collection is not known, but empty, invalid operation, exception or
argument exception seem most appropriate.
Exceptions give us priceless insight into what problems do we have in our application, and we should
never mask them with some generic handling that will hide the detailed information they carry.
So is it ever appropriate to have the exception clothes?
Well, it is in two specific scenarios.
The first one is the global cut block in our application.
This is the last resort of exception handling.
If something totally unexpected happens and there is no way of continuing the applications work after
that, we should simply show the exception to the user and store it in some logs after the user reached
the error.
The application will be stopped.
Let's add a global catch block to this console application.
In this case, we simply to the font color to read, and we printed the exception to the console in
applications with some proper interface, such a global catalog usually shows some error pop up.
Another case when catching any type of exception could be OK is when we don't intend to handle it.
We only withdraw it, possibly log it or add some additional information to it in such a timing application
as ours.
It doesn't make much sense, but in big projects, it's often the case that applications are multilayered
and each layer has its own way of reporting and organizing errors this way.
An exception thrown in the lower layer will be logged in each layer.
It crosses.
But finally, it will be handled in some of the upper layers.
If the exception is thrown in the data access layer, it can be intercepted in the business layer,
which logs it and then withdraws it.
It is then handled in the interface layer by showing some pop up with an error message to the user.
We'll talk more about how to resolve exceptions in the next lecture in a simplified way.
Such cold could look like this.
This is the lowest level player if an exception is thrown on data access, it's locked and ritual later,
it will be handled by the next layer, the business layer if the data access layer throws an exception
here, or if the processing of the raw data does.
The exception will be logged and written.
It will be truly handled by showing some error to the user in the uppermost layer.
The graphical user interface layer this way, the exceptions are wrong.
At the lowest layer of the application will be locked at each layer, but it will only be handled at
the graphical user interface layer, as you can see at this point.
It is not right or wrong, as this is the last place where it can be handled.
Of course, if any of the lower layers could actually handle the exception and continue working without
problem, it should not withdraw it and it would never be shown in the error window.
Let's sum up using cut exception should be avoided because it captures every kind of exception when
we decide to cut an exception.
We should know how to handle it, and it's not feasible is the exception.
Type is unknown.
We should be precise in both cutting exceptions as well as in throwing them.
During the interview, you could be asked what are the acceptable cases of cutting and a gap of exception?
Well, the first one is the global cut block that catches on exceptions not handled elsewhere and brought
them to the user.
And the second is cut block in which we throw an exception without handling it.
And the follow up question could be what is the global catch book?
The global catch block is the catalog defined at the uppermost level of the application that is supposed
to catch on the exceptions that haven't been handled elsewhere.
It usually locks the exception and source some information to the user before stopping the application.
All right.
We'll continue the topic of exceptions in the next lecture.
Thanks for watching, and I'll see you there.