Everything is working, but we still have a lot to improve, so firstly I want to do is go back over
to the browser and show you one or two things that perhaps is not quite working as expected.
Again, going to open up my console.
I'm then going to once again add in some code here that will definitely transpire correctly and bundled
correctly, but throw an error while it is being executed.
I'm going to put in console, dot whatever we've seen and air around this stuff before.
We should see some kind of error message that says L'Aquila blow whatever is not a function that will
be the result or the air that comes out of this.
I'm going to submit.
We definitely bundle and transpired correctly.
We passed that code down into the iFrame, but, well, we don't see anything inside the iFrame.
Instead, we get an error thrown at our console and error thrown.
Being thrown at our console is totally fine.
But remember, a user who is making use of our book application might not always have their console
open.
So if you write out this code, click submit and saw nothing happen, you would probably think this
is a bad application I'm using right now without any thought that, hey, maybe there's a problem with
your code.
So the first improvement I want to make is to make sure that whenever we eval a user's code, if something
goes wrong with it to the best of our ability, I want to try to capture that error and display some
message inside the iFrame telling the user, hey, sorry about your code is not quite working as expected.
So let's try that out back inside my editor.
I'm going to find where we are currently evading the users code, and I'm going to again wrap that with
a try catch.
Now, remember, as we saw a little bit ago, a try catch is not necessarily going to handle asynchronous
errors.
So if we ever have a set time out or something like that inside the code that we are executing, that
is going to throw an error at some future point in time.
This trick catch is not going to handle that.
But this is at least a good place to get started.
After we had in the tri catch and get this working, we can start to think about some other things we
might do to improve this.
OK, so.
When we catch this air, we're going to take that air, we're going to generate some kind of text message
and we could just insert that air message directly into that div right there.
If an error occurs, whenever a users code is being executed, nothing is going to be rendered into
there.
So in other words, if a user is trying to make use of this device to render a react component, we're
just going to pretty much overwrite that component that they tried to put in there with this error message.
Totally fine if we do.
So I'm going to first begin by just getting a reference to that element inside the couch.
They'll do a concert route is document.
Where he selecter.
Then I'll do a route dot inner HTML, so I'm going to forcibly write some HTML inside their.
In a place inside a div.
That contains whatever er just occurred, we'll just put in.
Er, like, so oops, I want to do.
Plus er er we go.
The notice that we have d'Hiv as a string plus air plus closing div.
Let's save this and do another test.
Now, if I do console, dot, whatever and submit, we get a nice air being printed inside there, so
that's pretty much the sign to the user of, hey, there's something wrong with your code.
Right now, however, showing this as plane kind of black text, not quite so great, maybe we could
add in some additional formatting just to make sure it's super clear that something went wrong.
So for that, I'm going to go back over.
I'm going to find that div.
I'm going to manually just add in some style to it right now.
I'm going to put in some style of color red like so.
Before printing out the air itself, I'm also going to put it right inside of this opening div, right
inside of that string right there.
I'm going to put in an H or.
That says runtime error.
Now, I've got a lot of quotes on this line right here, so please make sure that you've got all the
appropriate matching quotes, because since we are writing all this stuff into a string, your editor
isn't really going to help you out.
So please double check all your formatting, all the syntax inside of here.
And as you start to run this code, if you get any other kind of error, something that doesn't say
runtime error, well, chances are it's coming from this snippet right here.
All right, let's try that out onslaught dot, whatever, submit that's a little bit better, still
doesn't look great, but we can come back in a little bit, maybe add in a little bit better formatting
right now.
It's definitely very obvious to any user, I would say, that something went wrong and a user should
probably figure out what is going wrong with their code.
We're also giving them a nice message right here to say, hey, here's your hint of what's gone wrong.
And the one downside to this approach is that sometimes the air object that is thrown will have some
really useful message or some useful data inside of it.
So as an optional step, you can do this if you want to.
You don't have to.
We might decide.
After putting the message in there to re throw that er if we re throw the air, that will cause the
air to still be displayed at the console so the user can take a look at that air and figure out exactly
what is going wrong.
So again, totally optional.
Right after the rootin tml, we can read through air or just really throw air.
Now, if we run this.
And do our council, whatever limits, now, we get the very visible air message on the screen, but
the user can also see this right here, take a look at the call stack, all that kind of good stuff
and figure out what is going wrong.
Last possible thing you can do just to really exhaust some options here, we can technically change
instead of doing it through here, we can go with a console dot er.
Which will print up this air in a kind of air looking way at the console as well.
So there's the other way we can handle this.
Now, if I do my bad code summit, we still get stuff printed out here.
The one good thing about doing a console, er, if you're using some kind of monitoring software, it
might happen either you could do the ER or the console, but er I'm not going to try to speculate,
to be honest, on which way is going to be better.
Either one totally fine, but either way totally optional as well.
If you want to print the ER out today, fine.
OK, it's definitely a good improvement.
Still lots for us to do.
Well let's continue in just a moment.