So let's go back into the PowerShell console and we'll use the
TRY/CATCH syntax to capture the errors and exceptions, and then
we'll enhance that to use the TRY/CATCH/FINALLY syntax to
capture errors and exceptions.
So one of the ways that we can capture errors outside of
using error action or throwing errors is to actually try and
catch them in the first place.
So let's just go ahead and create the function that we had before, so
New‑Error, and then I'm going to throw an error here,
so Throw New Error, like so. And so we have our function, so I'm going to say
New‑Error, Enter, and what it should do is it should throw my error. Perfect,
nothing spectacular, it just throws the error.
Now, of course, if you have that in the code,
then, of course, unfortunately,
what's going to happen is when it executes the throw,
it will cause the code to stop executing.
So what we can do here is wrap things inside a try and a catch.
Now,
the idea behind the syntax here is that we can try whatever it is we want to do,
and then we can catch the output of that.
So I'm going to say,
Write‑Host and say An Error Occurred, and then close that. Now when
I Enter this, it will now not display the throw message, but will
display the message or perform the code action that we actually
asked it to in the first place.
So it's a nice way of saying, well, if we have functions that throw errors,
we can catch them gracefully and then have them do something else.
Now, we can look at this a little bit further because we can
throw specific types of errors as well.
So if I say New‑Error,
so we have our standard function, and then this time I'm going to say
throw, and in square brackets here I can say
System.IO.FileNotFoundException, and then just say File not found,
like so, Enter that one, and then close that function.
Now when I execute this New‑Error,
it will now throw a type of error called
System.IO.FileNotFoundException and render the message.
Now, of course, I suppose the question is,
how do we know that it actually rendered that
specific message or specific error,
which was the File not found? So let's go back and take that same one that
we've just generated, and we'll wrap it into a try statement.
So we're going to say try, and then I'm going to say let's execute my
New‑Error, and then I'm going to do this, and then go down and say,
I want to catch a specific message. And what I can do here is
say Write‑Host, and remember we talked about using the dollar
and then the underscore as one entry,
I'm then going to say $_. I should be able to then get the type of the catch
that's come through, so I can say GetType, and say go and get me the FullName.
I can then use that $_., and then I have what's called Exception, so I can get
that value too. I can do $_.Exception.GetType.FullName, so this should give me
the full name of the exception.
And then, to top it all off,
I can say Exception.Message, and then I can close that out
like so. Now notice what happens. We now get a full set of
information coming back.
Now, bear in mind, I don't have much information that came back,
but you can see that it shows the message, it says there was
an error, it has System.IO.FileNotFound,
which was the type that we kind of had, and then,
of course, it has the message.
So all of this information is captured whenever we
try to use the try and the catch,
and especially if we're trying to catch specific types of errors as well.
So what we can do is go a little bit further here,
where we're able to catch specific types of errors as well.
So right now if we just scroll back up here,
let's just move back up here, you can see that I simply just said try, run
the New‑Error, and then catch whatever was there. Now,
in reality,
I may know what the types of errors are that I want to kind of capture,
I suppose, so what we can do, and we'll just do the syntax for this, I
can say try New‑Error, run this one here,
say catch, and then at this point in square brackets I can then
determine the type or the strong type, I suppose,
of error that we wish to handle. So I can say FileNot, so
it should be FileNotFoundException, Exception is the first
one that we're going to catch,
and then I obviously have what I would like it to do, so Write‑Host Catch.
And then, of course,
we can go down and start adding another catch statement if I wanted
to, and go through and say System.IO.IOException,
which is one that's rendered when you try to open. And then we can go
and complete and keep adding, and adding, and adding.
So what we actually have here is the ability to go through and capture
specific error types and output the values that we would need to.
Okay,
so let's look at creating something a bit more real
here. So let's clear this out.
I'm actually going to paste in a specific function,
and then we'll look at the code itself. So you can see I've pasted it in.
It's the same function, so New‑Error,
and this time I've combined it with a string value so I can pass a letter A,
B, and C to a switch statement, and then I'm telling it to throw a specific
type of exception, so that's going to be our function.
So what does that look like when we execute it?
Well,
if we say New‑Error, and then you'll see ‑type and I can say A, you can
see it will throw a System FileNotFoundException,
which is correct.
If I rerun that and say B,
it should give me a System IOException, and if I run C, it
should give me the System Exception.
So we just have a function that's going to generate
specific typed errors and throw them.
Now, how do we capture this?
Well, let me copy some more and paste that in.
So here it is.
We're doing a try statement and saying New‑Error and passing the letter A, so we
know that A is going to be a System FileNotFoundException.
It will catch that based on the type, and then
represent the message that's here.
And then, of course,
we have one for each of the options that we've added into there.
So I'm going to do just Enter here, and it should come back
and say Got It: File Not Found Exception, and then it should
always render the finally option.
So what we can do now is go back here, and if I wanted to change that,
I could say, well,
New‑Error, so let me just go back through each of
the items and we'll do that one, that one,
that one,
that one, that one, and Enter it, and you can see it's now gone to the IO
Exception because we told it to generate that specific error, and so it's
caught the error and then has passed the value.
So, as you can see,
it's not the easiest thing, but as long as you understand
the errors that you're coming back with,
you can capture those and then redirect or transfer to other
functions or simply output messages to the end user.
So it's important to understand that you have this idea of throwing messages,
throwing errors or writing messages or exceptions, but in reality, you can catch those and make it do what you need it to do.