production of Python course, Sailor Academy. If this is your first time joining us, please start the course. I'll make sure the links are in the chat and the description below. We also have the full course you can take. And I will make sure, ooh, my apologies, everyone. I just had the live stream audio come into my headphone at the same time and it very much confused me. Anyway, I'll make sure the course and the program we're using Replet and our discourse discussion forums are available in the comments and they are available in the chat. And again, make sure you go back, check out our old videos and check out the course on sailor.org. But with no further ado, Dr. Sack, let's take it away and let's learn about some exception handling. Fantastic. So thank you, thank you. And so just wanna, well, we've already said it. I wanna talk about exceptions today. And so I wanna use this as a chance to maybe put a few things in context with regard to the unit. And just as a whole, because I encountered somebody yesterday when I was teaching them something. And I just wanna bring this point out is it's so important that when you're writing code that you learn how to debug small pieces of code so that you are really comfortable that you've verified that chunk of code basically. What I found with this one, and this happens all the time when I even say not to do it and students still do it. But just to have a mindset to think algorithmically, have a mindset to think in a methodical way so that if you, and don't assume that you sort of have a program that automatically works after you write a whole bunch of code. And what I was trying to get the student to do was sort of methodically step through a series of errors getting into sort of like the first level and the second level and to show that there wasn't just one error in the code, there were several errors. And how do you handle that? Well, the reason that he was kind of in that position in the first place was because he wasn't, he was assuming that everything worked, which we'll talk about that in a second anyway. So I just want, just as a piece of advice, whenever you get to a point where you've got like, maybe even when you're first starting out two or three lines of code, four lines of code, maybe an if statement, maybe a while loop, just have a hard to verify them so that if an error does occur, you know where the error isn't, and you start to eliminate errors in that way because you've verified code. And like, I know this section of code works, I know this section of code works, which kind of brings me to the next level of that. When you're first starting out in a programming course, you're not really taught initially to think about this stuff because it's just too much to think about. But I'd like to point out that there really are software design principles and there's concepts for software engineering. And not to be facetious, but I've gone to like student presentations, for instance, for software presentations, and they'll have a demo. And the demo, the professional demo is the, you know, that is the obstacle of eternity because getting something to work when you're demonstrating it to other people on a professional level is really, really an art more than a science in certain instances. But so students would kind of show me some type of software, maybe a chess game or some type of other, like a wild loop menu driven piece of software or something. And I could kind of see underneath the hood where they were going with their presentation and then they'd let you enter in data. And so that's when everything sort of, when you let the user enter in data, boy, anything in the universe can happen. So they'd have a message like, enter a number between one and four or something like that.  And my whole point, and again, not to be mean, but I'm just saying that you have to understand that when you actually do design real software that you don't have a lot of control over what people can do and anything in the universe can happen. So this is why when you're creating software, you have test routines and verification processes.  And it's very important. Like I said, if you're using it in the basement of your own home, that's a different story. But again, if you're planning on going in a direction where you're gonna be really like designing stuff, you wanna be careful about things. You wanna be aware that you can't make the assumption that your software is going to work, I guess is what I'm saying. Cause you don't wanna do that. You don't wanna design the software for the flight control, assuming that it works could put a lot of people in danger that way. So just to bring, and the alpha and beta test, I just don't wanna go off on too much of a diet travel. I'll go to my next slide. But and again, I wanna remain agnostic as your teacher. But I'm just gonna say like, if you are running a software company and you're sending updates out like every five to seven days, your management is either suffering from obsessive compulsive disorder or it's just a terrible company. And that's just the way it is. That's what alpha and beta testing is for. And some companies, they get so big that to put people in a position where we have to find errors for them is kind of like you're in this continuous alpha phase of design, which is just totally unacceptable when it comes to this type of process. Anyway, so part of the path to creating bullet proof, and this is really why I'm trying to put in context for today is the idea that when you're writing code, you wanna kind of create a safety net anticipating what types of errors could occur in your software. And that's again, that's a science, but it's also an art as well. And you wanna design gentle software landings for your code, however that happens. And so therefore we need code for error handling. And you may need to design like a catalog of error codes, if this error occurs and so on and so forth. But again, I think as much as humanly possible, I think the real key is to keep your program threads running in the event of really any errors, any errors whatsoever if you can do that. And so the real goal is to avoid crashes. That can be the unsatisfying part of using software, right?  I mean, someone didn't really do very good planning. And that's all that boils down to. And that's just a question of how professional software companies wanna treat their customers. It's more of a customer satisfaction thing. But I don't wanna go all the way down that path. I'm just trying to put in context how important exception handling is. And it's something that it's hard to bring up in a class like this, but at least it needs to be said. And then you can kind of be prepared for other advanced software design concepts. So for us, for designing exception handlers, basically, just it should be clear to you in taking the course that the flow is very similar to sort of if else blocks, if else LF blocks that you've written before. And if you're comfortable with those, excuse me, those conditional statements, that's really what we're doing. We're writing conditional statements, but it's at a more sophisticated level because we're trying to identify errors in those conditional statements. So a try block is gonna let you test the block of code, basically, and if everything is good, then it gets executed and there's no worries. But if not, then the error is gonna get caught and some error will be caught. And then you will transfer control to the accept block, which ideally will in some way handle the error to whatever degree you as the designer would see fit. And then you have the optionals. The optionals are the else and finally blocks.  And then there's a finally block, which is gonna execute independently of all the try, it's basically the rest of the code that you want to execute that'll always execute. And the word optional, I don't misunderstand what that word optional means. Optional means that in principle, you can design a try accept block without them and the try accept block will work. But I think when it comes to writing real code, you don't wanna leave them out. You wanna have else blocks and you wanna potentially have finally blocks as well because those are the chunks of code that are there to complete that safety net if I could put it that way. So we'll get into discussing all of these. Maybe it's a good time to come over to, let's say this slide, we'll come back to that one in a second. Let's get into this some kind of a replete of some kind. And so we should try and anticipate what types of errors could occur. And we'll just start really simple. I think it should be obvious what's gonna happen.  So all, I don't care what language it would be, excuse me, it would come out in the form of some type of an error, it might be a compile error, it might be interpreter error, it might be, but when we can characterize what the error type is, it'll help us. So if we go ahead and run this, we should see immediately that this is a name error. And this is the type of stuff you want to avoid. I mean, we don't care now. We're together in a class and it doesn't really matter. The world's not gonna end. The power grid isn't gonna go down. The telephone systems are still working. The planes are still flying. And so everything's fine. But when you see stuff like this, it can be, well, when you're testing, it's not a big deal. But if you have a program that's running and it does something like this, these red letters can be really, they're unnecessary. They shouldn't happen, is what I'm saying. And so, but before being able to sort of handle exceptions and handle different errors, we need to be able to characterize them and understand the universe of possibilities. And the universe is really quite large. All I wanna do today is just maybe talk about a subset of possible errors because once you get the idea, it becomes easy to characterize pretty much any, well, not, well, most any. Anyway, so that's what we call a name error. Another one that you're probably used to is if I said something, let's get that one off the list. If you do something like this, this is like a classic, this is a classic one, right? You wanna go ahead and take five and divide it by zero. There's gonna be a problem with that, right? You're gonna get an error that's called a zero division by zero error, a zero division error and error error. And so, these words are very, very important when you see them on the right side because they are honestly reserved words. They do identify that Python is taking exception to the line of code or the chunk of code that you're trying to execute. And then it's trying to let you know the exception that it's identifying, okay? And this will become important information for us in a moment. But right now, I'm just trying to, I'm trying to, the set of errors I'm picking are the ones that I've experienced the most with students really when they first start writing code. I think that's the biggest takeaway, the biggest deal. And so, name errors, division by zero errors, or if you would go ahead and maybe do something, let's say import the math, let's say, let's try another one. So let's, because we know the math library now, this is a good one to use. Maybe if I tried to take math.log of negative three, okay? And mathematically all should know that you don't wanna take the log of negative numbers. So, Python will take exceptions. We have what's called a value error. Again, a reserved keyword for the universe of possible exceptions that are sort of built into Python that Python is ready to look out for. And the reason is, is because you dropped a value into a function that isn't acceptable, it's unacceptable. So that's what a value error is. A value error is you called a function, you dropped something in and the function didn't like it. It didn't like the value. So that's a value error. Maybe if, let's see, let's just try a simple. Well, try something like this. Let's do this. What would happen? And this goes back to what I was saying a few seconds ago. So this is sort of a classic, you know, input a number. So you give instructions to the user and then you say, sorry about that, input a number. And oops, get rid of that. So make sure that runs, so we'll delete that one. So we wanna input a number. And again, classic thing would be like, okay, well, I'm being told to input a number, but I'm gonna input some text. And again, because of the fact that the input function is fine, the input function is happy with taking pretty much anything that you give it. The difficulty arises when you get that string back from the input function, that's not a number. Okay, it's not a number. You're gonna get a value error because when you float is expecting a number, now float is big enough, float is accepting and a float is robust enough to take, it could take a string, like that would be a three, a string three, quote, three, quote, and it'd be fine with that because that's what input returns text. And so float is emotionally prepared to handle data coming out of the input function that would be intended to be numerical. That's not the issue. The issue is if you tell the user to input a number and they input something else, and then you get about, so this is another version of a value error, okay? So value errors are typical types of errors that students oftentimes experience when writing functions, that they promised the function, they were gonna send one thing and then they sent it something else that it wasn't ready for, that it wasn't expected. So they broke their promise to the function and then the universe imploded. So that can happen. Maybe something like this, here's another one. So name error value errors, those are the types of things that you might expect would occur in an introductory programming course. Here's another one, try this one. I'm going to, maybe I intended to concatenate two strings together and then forgot to put the three in quotes or something like that. In this case, you'll get a type error because Python doesn't know if you want to add a value to three or if you want to concatenate a string to ASDF, okay? So the correction to that would probably be, you probably meant to do something like this and everything's good. So then you could go ahead and print. So that's a type error. Type error is when you're trying to mix and match types that they don't belong together. But if you can concatenate them together then that should be okay. And I love this, the timing of this example is so good. I got to share this with you, just blew my mind away. My son, who is eight years old, he likes to play Roblox a lot. And sometimes what will happen is that is that because people with higher privileges they'll be able to come into a game and they'll be able to do things that are not consistent with how the game is to be played in order to win the game. And so people in the chat box will start typing hacker, hacker, hacker, hacker like that. And that happened I think yesterday when he was playing and he said something, I just, I couldn't believe he said this.  And of course, any normal person that you would run into the grocery store would say, well, it's hacker, hacker because you're concatenating those two strings together. The plus sign is not to add hacker plus hacker but it's to concatenate them together. So when he said hacker plus hacker I saw two strings and quotes like this. And then so the plus sign connected them together and I said hacker, hacker. And he said, that's right. Like that was his answer. Like he agreed that that was the correct answer. So I thought, oh my gosh, my eight year old son without even thinking about it knows understands string concatenation. You know what I mean? Just like he naturally understands that. Eight year old son is smarter than me. I was like, two hackers? Is that two hackers? But anyway, so probably, so this would avoid that type error, you know. And then, so again, what am I trying to do? Let me even pull out some more, maybe longer ones. Again, the type of thing that you might expect. Let me pick this out here. This looks like a good one. This is gonna be the overflow, okay? So I like this one because I don't like it. And I'll get into why I don't like it in a little bit later, but the idea here is that you're gonna take like e to the x. You're gonna take something and raise it to a power x. The power is 10 to the second, 30 second power. So e raised to the 10 to the 30 second power is a pretty big number. And it's gonna probably far exceed. It'll challenge your computing resources if you have a 64-bit machine. And so in this case, you get, it didn't like it. It didn't like raising that number to that power. And so what? So if you go ahead and run this, you're gonna get an overflow error. And I'll talk about this, not so much directly, but I wanna come back to this in a second because I don't fully agree that that's the right answer for this. But anyway, that's what it is. That's how Python handles it. So if you see like an overflow error, it means that you've challenged the resources of your, you've gone outside, something has happened where the numbers you're choosing are gone far outside the boundaries of what a computer could handle, okay? Another common one just to, I think, and this is an important one, by the way, especially this is the type of thing that might happen if you're, if you put the camera, great. Good going. And then this can happen when you start to learn about lists, you know? And when you have a list, obviously the indices for A here would be zero, one, two, and three. So there is no A seven, okay? And if you attempt to make reference, and funny enough, again, different languages will handle this type of an error in different ways. There are some languages that believe you as the expert programmer, if you put an index, you meant to do it, and you know what you're doing. And it'll let you actually put an index that might not be valid for like an array that you created, but it leaves you alone. And so, but this one doesn't.  So again, index error is a key word that we can use to characterize, to characterize, you know, errors that could happen for ordered containers, let's say. Okay, let's put it that way. Let's say for the unordered case, here's an example where you created a dictionary and you've got the keys. And again, I'm just trying to, really trying to just go through the whole course of these different data structures we've discussed and what types of errors that could occur with them. So here we've got a dictionary, you've got the key and the value, key value, key value. So key string one, value one, key string two, value two, key string three, key string four, value four. And then you attempt to make reference to the key M, which clearly doesn't exist on the list. I think anybody can see that. And so in that case, you'll get a key error. So I think even starting with though that possible list I'll discuss more as we go, we get deeper into what we're doing here. I think the real issue is that, is that this red stuff on the right side, okay? When you start to see this stuff in the interpreter window, in the command line window, the question is, can we avoid any of those kinds of errors? And what do I mean by avoid? Avoiding, identify them, catch them, do something, take some action that would save us the hassle of seeing. And the answer is, yeah. So let's just introduce a try piece of code, let's say here. And again, we've already discussed this. We know that there's gonna be some type of a name error because I'm gonna make reference. And so the structure of a try accept block is very, it's very straightforward and it's totally consistent with Python syntax, with indentation, with colons, everything that works for if, else's, everything that works for while loops, everything that works for functions, everything that, all the syntax that works for everything in Python is based upon, this little colon up here and then the indentation to define the try, what's called the try block or the accept block. Now obviously, even Replet right now, this little squiggly red line underneath is trying to basically say, no, no, no, don't do that, but we're gonna do that anyway. And we're gonna, if we run this, the whole point is that we get that error and we have an exception of some kind, okay? Something has taken place. Now, I'll get back to this in a second. We haven't really defined what the error is, but at least we know in the invent of the error, this is kind of a fudge in some sense because, and this is the way that you can write code sometimes almost subconsciously without really thinking through what the answer should be. So probably the more correct statement, even though we already know, because I told you about five minutes ago that this is a name error, that the, so you know that right now, but really what I should say here is like some kind of error occurred. You know what I mean? You really don't, all the accept does is that it knows something went wrong. And I'll come back to this in a second. That would probably be more accurate, okay? So just because you have the accept block does not endow you with the knowledge of the type of error that occurred. Now I'll come back to that in a second, but the only reason I put the first one in there first is because we know it's a name error and now you put the message, but it really could have been any kind of an error. So probably the more accurate measure would be some kind of error occurred. So just, you know, note that and we'll come back to it. So that's a try accept block. So maybe what we'll do is something like this instead, right, where we've got the accept and now what we're gonna do is we're gonna make the exception dependent on the actual type of error, okay? And now, and this is a big deal. It's a big deal because you as the expert program now are actually attempting to identify using those Python keywords, identify the type of error that occurred and therefore take some type of action based upon the error that occurred. In this case, it's pretty mundane, there's nothing going on, but the message is clear. The message is correct, okay? Is that when the name error occurs, the variable, just the reason it happened is because the variable wasn't defined. So now I'm being very specific about what the name of the error is and then otherwise, if something else happened, we'll have another accept in there for something else. So if I said something like A is equal to three plus going back to the other example that we said a few seconds ago, that if you run this, some kind of error occurred. And again, just it depends on why you're writing this, why you're, what your intent is, but you wanna be clear. And also one other thing, by the way, is that when you write this code, the order in which the exceptions are addressed is exactly the order that it will be addressed, okay? So if you have a list of exceptions, the test is gonna go sort of from top to bottom sequentially. And the first exception that matches your issue will be the one that's addressed. And that'll make a little bit more sense in a second as well, but that's the main idea. So I think part of the art of designing exception handlers is A, being able to identify all the possible errors and then taking the right action based upon that set of errors. And again, this is exactly why you have alpha and beta testing is because especially when you start writing very, very large software packages in large companies where large numbers of people putting large things together. And we just have to have some methodical series of steps that allow you to sort of coalesce all those pieces together and so this is the first basic step at the 105 level of how you begin to even broach the subject of writing software like that, okay? And so again, so or you could have something like this if you just come back to, you know, it's another example. Clearly, something isn't going right, but it's not a name error. It's obviously not a name error. That's not the issue. All right, I think there's enough said about that. Let's see here. So when you write handlers, okay, when you go ahead and write handlers, you're allowed to make the list pretty much as long as you want to, you know? And so in this case, you know, you'd have a value error. If there were a value error, there could be a name error. And so the value error we said already is, you know, is gonna be related to when you made a function call and the function basically spewed, it said, I don't want anything to do with this. So now what you have are blocks of accept clauses basically, each one is servicing some different, you know, possibility based upon this allowed set of keywords that Python, you know, has tried to come up with a, you know, as exhaustive as possible, tried to come up with, you know, a list of cases for exceptions. And then if not, then you as the software designer get to, you know, design your own handlers for whatever, you know, cases you would want to design for. So this is just, so my point is that, is that you can go on and on and on with accept clauses. There's no stopping it. And you can, you know, I mentioned this briefly and it's mentioned, definitely mentioned within the course is that, you know, you don't have to sort of unravel every possible exception with keywords. There's syntax where you can have an accept with many possible errors listed, you know, like as a tuple basically, as a tuple. Again, I'm not gonna go there today, but there's different ways of addressing multiple errors, I guess is what I want to say. And that's probably more the direction that I want to go in as we go deeper. But then, so that's the try and accept. If we add on the, like a try accept else type of a thing, in this case, you know, you have A is equal to hello world and there might be an exception and there might not be.  But if A is well-defined and there was no error, then you want to possibly service, you know, the exception and do something opposite to what the accept was doing. And in that case, you would use something like an else. And this wouldn't be code that would be running for all cases. This would just be in case the error doesn't occur. And so if you do that, then you'd see the value printed out and then the else actually executed. So in some sense, as I said before, you know, the structure of try accept else blocks, you know, very similar to what you've already done for if else, so it should be like a really natural, it should be a very natural step to, you know, write code for handling exceptions. I mean, again, at the basic level. All right.  I think you're all getting that at this point. It's gonna be some type of a name error. And so the exception occurs and we handle the exception and that wasn't really handled in the brightest of ways, but at least it lets you know an error occurred. And then with finally, so, but the whole point is that you're not getting that red stuff thrown out to the screen. You know what I mean? That's really the thing that we want to avoid this long stuff that gets thrown out and we don't want that, you know? So that's what this print statement does.  So in this case, the error did occur and then we moved on to the rest of the code that should continue executing. And again, that's kind of, you know, the finally is there for the crash proofness, you know, that if the program can continue, it should continue. And that's really like the way that you wanna design software. And there have been some really good packages out there that actually do that extremely well, extremely well. And like I said, but I think that's the way that you wanna design your code. And I know, again, like in an introductory course, that isn't usually like the most important component. I think that like when you're first learning, you wanna get the syntax, of course, wanna get the basics, you know, one sort of loops, conditionals, functions, methods, you know, objects, these types of things. And then of course, we kind of, we wanna grow out of that infantile state basically to assume that everything that we write is going to work, okay? Like probably that's actually not the case and for more, you know, complicated pieces of software. Again, you know, with millions of lights of code and documentation that would go from here to the ceiling, you know, those are the places where this really matters. And so it's hard to, it's hard to impress in a course like this, you know, the importance, the criticality of understanding how to write code like this. And it's not that big of a deal, but it is extra work.  They're more time consuming. And sometimes when like, when you're just in a mode where you're like writing software, you just wanna get something to work really quick and you type it up. And if it's just for you, it's a onesie or twosie, it's not that big of a deal.  You just wanna be aware that up until this unit, that's not how things work professionally, I guess is what I would say. If I could put it that way, you know, cause you have to learn, you have to get, you have to walk before you can run. I guess I would say that, put it that way. All right, so let's imagine that you're going to write a real exception handler. I mean, you're really going to come up with an outcome, design an outcome for your program if a certain type of exception occurs and you want to have this kind of soft landing or allow the program to continue. I just, I wanna show you some elements that I think could turn out to be quite useful when it comes to protecting from, you know, let's say numerical, you know, numerical fatalities, potential fatalities. I think probably a few are the best and there are others. Like I said, when you design code, you'll work with people to come up with error codes, basically, you know, this number means this, that number means that, you can go a big matrix of everything in the universe that could go along. And, but I think as a start to that, it's good to remember that the value none is a valid Python keyword. So if you have code and you catch an error, you know, you may want to return a value like none from your exception handler because on the other side of it, like if you return from some routine of some type and you can write your code so that if this value is equal to none, then you know something went wrong, right? And none sometimes will separate itself from the other set of, it may not, I'm not saying there always does that, but maybe you were expecting a string or a dictionary or a, you know, or whatever, you know, some type of data type or a number, something.  And so it's kind of like a path to a soft landing. I want to alert you to something else too. Again, this isn't something that, again, it's like, there's so much to talk about. It's almost like in my universe, you know, I think everybody knows this, but then I realized probably not, you know, not everybody knows this, but when it comes to like representing numbers, there are values, there are valid numerical values for indicating positive infinity, negative infinity and something called not a number. And, you know, what is that? So positive infinity could mean, for instance, like that e to the something that I just showed you a little while ago, e to the 10 to the 32nd power. And in those circumstances, that would be, when you start to go outside the boundaries of the positive numbers that your computer could represent, that would be a positive infinity. Or if you go in the direction of a negative number, then you could go towards negative infinity. If just went to, if the number went to negative, or if it results in something that isn't really defined, like zero divided by zero.  But if it does turn out that you get a form like this and you can't handle it initially, that zero over zero would probably fall into the realm of not a number.  So infinitely plus three is equal to infinity. Or if you tried to take infinity plus infinity, you know, that's still, sorry about that. Let's see, that was B, case sensitive. That would give you infinity as well. Or B plus D, if you tried to add infinity to not a number. Again, I don't know, so you get not a number. Again, I don't have time to go into the, you know, sort of the algebra of all the rules of not a number and infinities. If you know them great, if you don't, it's not a big deal. But here's the deal, that if it gives you a way to create values that would go outside the realm of values that your method could return. And I think that's important to know. Like, so for instance, maybe you have a function that's trying to find a value on a list and it doesn't find it. Well, then you might return potentially, if you agree that you're just gonna use positive indices, you might return to you to use a negative, return a negative number. So sometimes methods or functions and part of the error handling process in terms of the exception handling process, it's a good idea to think of values that you might wanna return that wouldn't be in the set of things that you were processing and to be able to use that as part of your error handling. And I'm just throwing these out here as ideas because they can be useful that, you know, they set themselves apart from a lot of calculations that you can make. And again, you know, I don't know where to bring this up in the course. It may have been best for me to bring it up like when I was introducing floating point numbers, but it's so early in the course to bring up the concept of infinity, you know, at that point that I just didn't, I didn't feel that was the place. This unit, I feel like it's the place where this is good information to know if you really ever have to like design an exception handler because you'll find that you're always looking to return something that's outside the set of realm of possibility of things that would have been computed. So these could be useful values. So I just wanted to, you know, say that and make that a major, major point because that's part of, you know, writing error handlers in general. Let me grab this piece of code and have a discussion now about, just about exception. So we'll go back to our division by zero error. And the, when it comes to this, this is really a Python thing or it's a language thing is that you as the language design, people if you're trying to design Python and you are trying to characterize the universe of all possible errors that you would want your language to have built in to be able to catch. And you would do it in a hierarchical way. You would, again, if I left you alone on a desert island take my word for it, that's the way that you would do it. And so the error catching has to be hierarchical because it's up to, you wanna leave up to the programmer the sort of the universe of possibilities for a given type of error. And so in the Python hierarchy, there are what are called arithmetic errors. And underneath arithmetic errors, you could have various arithmetic division by zero. You could have overflow, the one that I showed you a little while. So if you were to run a piece of code like this at first glance, this is obviously a division by zero error. Okay, but what I said before was that when you process the exceptions, just because of the way a sequential processor in a language has to work, just the way if else clauses work, by the way, if else eliffs work is that you sort of, the first thing that you see that you satisfy to be true is the potentiality that you execute. And then once you execute that potentiality, you're really not gonna pay attention to the other ones. And so that's how the except hierarchy is going to work in terms of the code is that if a division by zero error is gonna be arithmetic that you're most likely going to see this one first. So that would be my guess if I had a chunk of code like this because arithmetic errors encompass a wide range of errors. Now, if we go like this and we put this, for instance, second, like so, then you'll see the zero division by zero error. Okay, because the zero division error is a subset of all possible arithmetic errors. So like within the course, and this is what I was kind of showing, let me come back over here for a second. There's reference that's made to this webpage because this is kind of like the Python documentation for Python three. And you should know, if you haven't ever visited this site by this point in the course, you really should. Again, it's not necessary to make the course work, but it gives you on a more technical level how Python works in general. And if you go, and this page is listed within one of the pages of the course and it gives the hierarchy. It kind of, the largest, so this will become so much clearer in the next unit. But again, everything in Python is derived from objects defined by classes. And so the largest exception class is gonna be the base class. It's gonna be the base exception. So you could search for a base exception and basically you're looking for pretty much anything underneath the hood, which isn't gonna be very helpful. So then what you try and do is sort of methodically, hierarchically, break down to whole bunches of errors. And then as you come down to this list, you'll see pretty much exactly what I just told you is that in the set of arithmetic errors, you can have several different types of errors. And I just wanna make you aware, when I used the word hierarchical, this is what I'm kind of picturing in my head. And in terms of just having a process for understanding the universe of possible errors that could occur. Again, as I said, if you really start to do this stuff, you may find something that's not on that list and you may have to design something separately to do that. But you have all the hooks in a language like Python to do that. And then the second thing in terms of execution, it's so important to recognize that there's an order just like as with if else classes. I can't emphasize this enough is that the ordering of how you specify these exceptions. Now you can see why if I put the arithmetic error first that that's what's going to happen. So I think like some total, I can't sort of just for an introductory discussion, I can't think of too much that I also that I want to say, I just wanna get across the importance of exceptions and try else finally and accept understanding those key words. Understanding at least some of the errors that you should expect would happen at an introductory course. And then just in terms of the hierarchy of how you arrange your accept statements based upon these predefined keywords that define the kind of error that occurred. And then lastly, just the idea that when you design your accept clauses, they're gonna be pretty much executed in the order that they're encountered. And again, that should appeal to your understanding of if else and LFs, okay? So I think with that introduction, I think it's probably sensible to maybe play around with some examples just to kind of make sure that, you know, we're good with all of this, just going back to a simple, maybe a simple try example, try accept. You know, maybe we wanna write a function that does something like this. So this function is going to, and again, I reserve the right to use the math library because again, that was visited many eons ago in the unit where we talked about functions and so forth, which kind of introduced the notion of how to import something, import a module, the math module and all, or a large number of methods that can be called from that module. One of which is the square root. And so if you enter the number and everything's good, well, then we're just gonna return under the try condition, we're going to return the square root of that number. And then otherwise, what we're gonna do is we're going to, you know, print something else. Like if it's a value error, the input argument, for instance, would be non-negative and then you would return, in this case, a negative one. And so if we compare and contrast, let's say this versus, you know, taking the square root of negative two, I'll make mention of something else in a second. Is that the, so here's where if we didn't have this, you know what would happen is, you know, if I just said, let's say, maybe you don't, so we'll do it, maybe you don't.  So when you, I just wanna point out that that there is a CMath library that handles complex numbers. So it is possible to take the square root of a negative number, okay? But in the instance where you try and take the square root of something, you have to have something in place. Now, the return function is going to, is gonna return a value of negative one. And so this is where I'm saying, well, when you return something from your exception handler, that you're going to return a value that isn't in the spectrum of possible answers the function could give you. So when you take a square root, it usually means for the function, it's gonna mean take the positive square root because there are always two square roots. You get a positive and a negative, but it'll just return the positive one. And so it would be safe as part of your exception handler to return a negative value because that isn't something that you would expect to get from the function itself. Let's try another one. Over here, I, again, going back to making this point to get about not a numbers and minus infinities and handling values that wouldn't be what you would want, let's say, from a division, okay? And so there are degrees of infinities. There are degrees of pathological, numerically pathological behaviors. And so in this case, if we tried to divide three by four, you'd expect that you would get a value back. But like if you tried to divide zero divided by zero, that type of division by zero, it wouldn't be, you'd want to characterize it. Like it wouldn't be necessarily, that wouldn't fall within the potential of like an infinity. It would be really a not very well-defined number in the absence of any other information. And so in this case, you actually might wanna go through the work of returning not a number. Otherwise, if you had the instance where the numerator was less than zero, you'd be taking like negative five divided by zero. And it really, that wouldn't fall within the realm of not a number. It really probably would be more like a positive infinity approaching a positive infinity. And if you took a negative number and divided that by zero, then you'd go ahead and get negative infinity. So now what we try and do is we try and handle these different kinds of divisions. Or if I said, if I wanted to write something like this, and honestly, whenever you, if you really wanted to, if you really, whenever you pull out that division sign, you really want to make sure that you've got those numbers can't well characterize it. You know, a program killer, like an introductory program killers is when it's assumed that the denominator isn't equal to zero when it actually can be. And so you really, whenever you pull out that division sign, you always want to watch that denominator as closely as possible, because stuff happens. So again, so these are various, oops, sorry. Made a mistake there. That's true. Let's say negative five divided by zero. Okay. And so just different cases that you might want to characterize your division by zeros. You don't have to do this. I'm just trying to give you examples of, what I'm really, the point of this example is really to demonstrate to you that there's a whole bunch of stuff that can go into the exception handler, for further analysis of what the error is. So, I know I started out with these one-liners because I'm trying to get the point across of like, try accept Elson finally. But usually, if you're really writing these things, you can have quite a bit of code in the accept block depending on what you're trying to accomplish. Okay. Let's do another one, just a natural one that you might encounter and just go on and on and on and on about this. So, here is an example of using else. Okay, and the point of this code is that you're always wanting to return something if you can keep the code going. The goal is always to keep the code going if you can. If it's sensible, if it makes sense. If you have to stop the program, then so be it. But if you want to keep the code going, you've got to have parameters that give you the ability to have this soft landing that I'm talking about. So, if for instance, for some reason, I'm gonna try some code that would call this function. I send a list that has only zero, one, two, three, four as the indices and then the list, again, this is probably, I would have to say, one of the most common errors, again, are index errors when students first learn how to make lists, how to create lists because the danger is that you're trying to make reference to an element that doesn't exist on the list. The index doesn't make sense. So, in the case of an index error, yeah, well, definitely if you want to print the message, but if you wanted to keep the, you know, to keep main going, what do you do? Well, you wanna return something because in the else condition where there isn't, what's happening is that there's a minus 99 that's being appended to the value of A list. So, if there is no error, if there's been no error, you're gonna return something that's a list. Well, what do you do if you get the error? You know, you might wanna return a none because it's kind of like a null value that you could write extra code down here that would say, hey, if none, then do something else. It's very typical, like, again, we're going back to, for things like memory allocation, big, big, big, big deals that you always wanna check to see whether or not the operating system gave you a memory. And when you check for the file, you wanna make sure that the file actually exists.  Okay, so in this case, the index error, trying to index, trying to access indices that aren't on the list, and the program ran fine. Okay, there's no red text, it didn't crash. The program is ready for the next thing. I think that's a really good way to design code, okay? And then maybe one more, I guess, yeah, I'll try this one down here, just to kind of throw them all together in the time that we have. So in this case, there's gonna be some type of op test. And so now I've kind of thrown them all together. And this would be, you know, similar to, you know, what you would want to do if you wanted to integrate everybody, you know, bring everybody into it, to try the optionals, try accept, and then the optionals else and finally. And everything, something's going to happen in every one of these cases, okay? In the first case, we're going, well, the try is just gonna try and allow you to input a number, but now we're really, really gonna watch out, make sure that, you know, if we don't input a number, what are we gonna do? Well, if there's no error, then we're going to, then we're going to take that value, add three, two and divide it by five. And then the finally, and this is the key, I think, this is the key, you know, that we probably end with, you know, just given the time is that, the key is that the finally is going to execute under all circumstances. So the finally returns something under all circumstances. And in the first case, if the error would occur, well, it's just gonna return not a number. In the second case, if our error doesn't, it's gonna compute this. And then finally, that's what's going to get returned. So if we run this and, you know, I input the number of four, nothing wrong with that. Everything's good. Then I'm just gonna take four, add three to it, take seven and divide it by five. If I do something like this, oops, sorry, what did I do? If I do something like that, okay, the error is that you say, well, you didn't input a number, but now a value also gets returned. So this is the kind of structure that I would say that, you know, if you were just doing it for yourself, it could be kind of a pain in the neck because, you know, if it's a onesie-toosie kind of a thing, the worst that happens is you get that stuff out to the screen. But again, in the event of somebody else is using your code, okay, then probably you wanna be, you know, a little bit more in the camp of people that would be designing soft landings. And that's the whole point is that there's really, I'd say the three major things are knowing the keywords for what types of errors you're interested in detecting. And then being able to write the hierarchy in terms of sequentially dealing with all the possible except possibilities. And then being able to sort of arrange the try, except else and final ease, given that hierarchy so that you have a nice smooth bulletproof piece of code. So I think I'll probably stop there because it looks like we're on time. So that worked out well, almost perfectly. Yeah, that was great.  We haven't had any questions as of yet. Well, that I couldn't answer anyway. So we'll give it another second. And while I'll just mention that I saw, Python came up this weekend and I found out that Netflix does a lot of their backend coding on Python, which I found interesting. Yeah, probably so. And it's a great language for development. And then you got to get for the deployment. So again, so for this course, it's like this is all for development. What IDE would you want to use to develop code on and stuff? We picked this one because it's easy, it runs on the web. You would use something a little bit nicer. And then you got to go from the Python code to some executable system that could be deployed independent of the IDE. And so yeah, so there's lots of hooks out there to be able to go from point A to the final place. Because right now this is only interpreted. But yeah, I mean, I think a lot of people these days are doing their development on using Python because it's just so seamless. And there's so much, there's just so many modules out there to do so many amazing things. It's outrageous. It's outrageous how the community of Python building and Python developers has just exploded into some of the coolest tools that you could pay a lot of money for it elsewhere, like OpenCV for instance. OpenCV is like a computer vision type of module. And the stuff in there is ridiculously powerful. It's close to bulletproof a lot of it and it's free. And it's actually free. So yeah, Python's great, you know. Well, I think we're good here. I think we should definitely say, well, thank you for, as always, Diver Sack for helping learn us. We'll be back next week at the same time for the unit 10 wrap up. If you haven't caught us, if you haven't caught up yet, make sure you go check out the other videos. If you've watched this whole video and you're like, I'm confused, go and watch those and take the course. All the links are in the description below and we'll see everyone again next week.


Great, good afternoon everyone, thanks for joining us this Monday afternoon at the start of our Climate Adaptation Data Week online briefing mini-series. I'm Dan Berset, the Executive Director of the Environmental and Energy Study Institute. And on behalf of everyone at ESI, I hope our briefing audience today is hanging in there and feeling well. Today marks the one month mark from the first time we moved the briefing online to encourage social distancing. It feels like a lot longer than a month ago, and we probably still have quite a way to go before we see you again in an in-person ESI briefing. But we must keep up our work to build awareness of the policy challenges and solutions to advance climate mitigation, adaptation, and resilience. So thanks for being with us today. For those joining us for the first time, ESI has undertaken a briefing series to explore climate change solutions and resilience strategies in coastal communities across the US. These briefings are intended to inform policymakers and the general public about the challenges and barriers to improving the resilience of coastal communities, and very importantly, share some success stories about how adaptation can be cost-effective, nature-based, and equitable. If you've missed our briefings to date, be sure to visit us at www.esa.org for video recordings and written summaries. We still have two more areas to explore, Alaska next Tuesday, April 21, and on a date to be determined for Puerto Rico and the US Virgin Islands. When you visit our website, you can find out for our bi-weekly climate change solutions newsletter to help stay informed and up to date. Today, in the rest of this week, we are doing something new for this briefing series, and ESI. Since our last briefing on Hawaii and resilience financing strategies on March 20, as we said we would do, we took stock of how our new online briefing model was working, thanks to everyone who offered feedback, and I still encourage everyone to take a few moments and complete our survey after today. While we will continue to hold online briefings that follow our traditional in-person model, four or five-person panel, a 90-minute format, we also got a little creative. The dynamics of an in-person briefing are just different than they are online, and so are the logistics and planning. Given this new medium, what could we do now that before would have been too much? How could we adapt to our new circumstances? One idea that we are kicking off today, a week-long, regularly scheduled briefing mini-series to explore a topic in greater detail. This mini-series will feature shorter individual briefings and fewer panelists, and the exchange between moderator and, in the case of this week, moderator and co-moderator and experts would lend itself to a more conversational style. You can find the complete schedule in this briefing mini-series online, www.esa.org. So here we are, on the first day, to hear from two experts about the topic localizing sea-level rise projections for decision-makers. After the presentation, my colleague Amber Todorov and I will co-moderate a discussion, and you can participate too by following us on Twitter at EESI online and by sending us your questions. You can also send your questions to EESI at EESI.org. Today we are hosting two experts. Let me introduce them now and then get out of the way of their presentations. Let me welcome Dr. Ian Miller, Washington Sea Grant's Coastal Hazard Specialist. Ian works out of Peninsula College in Port Angeles and the University of Washington's Olympic National Resources Center in Forks. Ian works with coastal communities and public agencies on the Olympic Peninsula to strengthen their ability to plan for and manage coastal hazards, including tsunamis, chronic erosion, coastal flooding, and other hazards associated with climate change. After Ian, we will welcome Nicole Fagan, who has worked for 30 years as a land use and environmental planner and lawyer specializing in coastal loan management and waterfront planning issues. At Washington Sea Grant, Nicole focuses on alternative shoreline stabilization, coastal resiliency, and working waterfront issues. Among her projects, Nicole helps local governments develop their capacity to address sea level rise. She also manages Green Shores for Homes, a multi-agency effort to create a voluntary rating system for shoreline homeowners who want to support healthy marine ecosystems. Ian, Nicole, welcome, and I'll turn it over to you. Really looking forward to your presentation today. OK, thank you so much, everybody. So my name is Ian Miller, Coastal Hazard Specialist of Washington Sea Grant. I'm going to be your part one speaker on this presentation focused on innovations to support sea level rise planning with a focus in Washington State. And then, as Dan mentioned, Nicole is going to follow me. And we're going to focus on a project that we recently wrapped up that had, as an element, this effort to localize sea level rise projections to better support coastal managers and decision makers with the hopes that sea level rise would be incorporated into planning efforts. Most of what I'm going to focus on is embedded in the updated sea level rise assessment that we published in 2018, which is shown here on the screen and is available at Wachostlenetwork.com. Before I get there, though, let me just introduce Washington Sea Grant. Washington Sea Grant is a national oceanic and atmospheric administration program, and we are housed at the University of Washington. Although, as Dan mentioned, many of our staff are distributed around the state, like myself, and we fund and conduct marine research, education and outreach programs throughout the state of Washington to support the health and sustainable use of our marine resources. We've got a variety of focus areas. As Dan implied, I work in the area of coastal hazards and coastal resilience, as does Nicole. So let me dive into the main content today, the main purpose. I'm going to start back in 2014 when Washington Sea Grant conducted and then published a survey that went out to coastal managers and decision makers around the state of Washington and really was trying to get a sense for their needs in regards to planning for climate change.  This is a table of a variety of climate impacts, and those, the respondents to the survey were asked how important each of these climate impacts was to their community. That's the blue bar, and the scale there is percent of respondents from zero to 100. And then the red bar is, do you have what you need to plan for that particular impact? So you can see for all these impacts, there are gaps. There's a big gap between the importance of the impact and impact and what they, what those planners and decision makers think they need. I'm going to hone in on the sea level rise bar, which you see here, where you can hopefully see very clearly this big gap, which I'm going to frame as an action gap. We perceive this as something that told us there was something missing in terms of the information available to coastal managers and decision makers in the Washington state in regards to addressing sea level rise or planning for sea level rise in their communities. And this one was particularly interesting to me, because in 2012, just two years before that survey, we had had quite a rigorous sea level rise assessment published that was intended to be specific for the West Coast of the United States, including Washington state. So this is a publication called Sea Level Rise for the Coast of California, Oregon and Washington. It was a public report published by the National Academies of Science. And so again, this was published just two years before that survey. But there were a variety of reasons why we thought, based on our conversations with planners and decision makers in Washington state, that this was not being incorporated into planning in the ways that one might have expected, given the type of report and assessment that this was. And there was two things that I'm going to focus in on that we set out to address in our updated assessment that was published in 2018. One was in the sea level rise scenarios that were embedded in this report, there was a very narrow range of uncertainty. So what I mean by that is that really the sea level projections themselves were communicated as these kind of narrow lines, these curves, if you will, but didn't have a way to communicate really well the uncertainty in sea level rise projections, especially moving forward into the future. This really became an issue for those planners and managers that we interact with that are quite savvy about following the literature. And in particular, we're focused on some of the projections emerging at that time from especially places like Antarctica that suggested much higher magnitudes of sea level rise were possible than were communicated by these very narrow projection ranges. And that created questions and confusion about how to address that possibility amongst those managers and decision makers. The other thing that we felt was not included in this assessment that was problematic for many of our constituents was that it was not localized for most communities. And so what that means is that the projections were, it wasn't clear if the projections as published were intended for an individual location on the Washington coast. And this will become, it'll become clear what I mean more specifically about that in just a second. So in 2015, we framed and proposed to NOAA a project under their regional resilience grant program that had four objectives that are listed here on the screen and a wide variety of partners, all of whom I won't list, but there are logos on the left side here. We wanted to support an updated sea level rise and storm surge assessment for coastal Washington. That is the part that I led and it's highlighted in red here. And then I'm going to focus on a little bit more. We also wanted to build climate resilience principles into state agency processes and plans. We wanted to look for resilience co-benefit from existing planning processes and investments. So we didn't want to build new sea level rise focused programs, but rather figure out how to leverage the investments we were already making in Washington state and then create outreach tools to facilitate implementation of resilience projects and plans. So again, I'm going to focus on that top bullet, some of the innovations we built into the assessment. And then Nicole Fagan is going to follow me and address some of these other bullets. So I'm going to focus in particular on two innovations that we built into that assessment that we felt like addressed some of those shortcomings of the 2012 assessment that we were following up on and hopefully serve to fill that action gap that I highlighted at the beginning. So the first thing is we incorporated a probabilistic framework for communicating sea level rise projections. This was published in 2014 by Bob Kopp. And I'm including his photograph here just because his contributions and his work really allowed us to do this. So I wanted to make sure that Bob gets the appropriate credit for that contribution. And on the lower part of this slide is a graphic representation of what those probabilistic projections are. This is a set of sea level rise projections. And these are for Washington State. Down at the bottom you have time out to 2100. And then on the y-axis you have change in average sea level and feet relative to essentially the contemporary average. And then we've got a bunch of lines that sort of feed off from the observed sea level trend in Washington State. And it has very much the same look as sea level projections that you've perhaps seen before. These kind of curves that some of them are quite steep. The difference here, though, and what's been added are these percentiles that are arrayed along the right hand side of this figure, which are assessments of likelihood associated with a particular curve here. And it's that assessment of likelihood that really gives this probabilistic framework its power, so to speak. Because what we think and what we've seen at play is that it allows communities to do some more nuanced decision-making and some more nuanced discussion about sea level rise vulnerabilities depending upon where you work within that likelihood range. So this probabilistic framework was one thing that we wanted to and did build into the 2018 sea level rise assessment that we published. The second thing that we built into it, the second innovation, has to do with localizing. And this slide is intended to convey why that's important, especially in a place like Washington State. So these are tide gauge data. These are observed sea level data from two locations in Washington State, Nea Bay, Washington, which is on the tip of the Olympic Peninsula, and Seattle, Washington. Now these two locations are only about 60 miles apart as the crow flies. What you're seeing here are long time frame sea level trends. The top one in Nea Bay, this record goes back to the mid 1930s. The bottom one from Seattle, the record here goes back to the late 1800s. And these blue lines are monthly average sea levels recorded at both locations. And the key thing to note here is the trend in sea level, what we refer to as relative sea level at these two locations. In Nea Bay, sea level is dropping. Whereas in Seattle, sea level is rising. The ocean is doing the same thing in these two locations. Again, they're quite near to each other. What's different here is what the land is doing. And so land movement is a critical element of understanding sea level rise projections, as well as observations at the community scale. As a consequence for that 2018 assessment, we invested actually quite a bit of our energy, not in what the ocean was doing, what sea level in the ocean was doing, but what the land was doing, how the land was moving vertically. This is our summary figure. These are, this is the shoreline of Washington state in outline. On the left hand side, the colored figure is our estimate of vertical land movement with hot colors being uplift and cool colors being subsidence. And these are expressed in feet per century to align us with the same timeframe and units that we used for projecting sea level. And then on the right in the bluish tones is a estimate of uncertainty for each of those sections of coastline. So what this allowed us to do was take our Washington state probabilistic projections, couple those with these vertical land movement estimates at every location along the Washington coast, and essentially come up with what we call a relative sea level projection, a localized projection that was applicable for every community. So what we developed as a consequence of that was an interactive map. You're seeing a version of it here that allowed a community planner, a person at a particular location or interested in a particular location in Washington state to go in, click on their location, and then download a set of information, a set of seal rise projections for their particular location on the Washington coast. Now, originally, and at their core, those projections are served essentially as a matrix. And this looks onerous when you first take, when you sort of take your first look at it, but it includes some pretty useful information that allows you to get some pretty interesting insights about sea level change in your particular community that I wanna highlight before ending by showing you what we've switched to, to get away from sort of the immediate reaction to a table like this. But there's really three ways that you can sort of use this matrix approach to provide insights about sea level rise at your particular location. The first is obviously you can focus on a particular timeframe of interest and get a sense for the full range of uncertainty across that timeframe. So I'm showing you here, 2100, and embedded in the table are feet of change in sea level. And here we can see by that time, we've got a pretty significant range of uncertainty, 0.3 to 8.6 feet. But we can also focus, of course, on our best estimate or a narrow range in the likely zone. If we wanna tie our decision-making to a particular risk tolerance, we can focus on a particular likelihood set. So for example, I've highlighted here the 50th percentile, what we might assess as being our current assessment of the most likely sea level scenario for the future. Or finally, if we have a particular decision or a particular use that we know has a threshold associated with it. So if sea level changes by X amount, we will start seeing impacts. We can trace that threshold through the table to get a sense for when and how likely those impacts are. So again, the idea here is that you get some insights from this approach that you don't necessarily get from what came before. However, acknowledging that those tables are hard to digest in many cases, our colleagues at the Climate Impacts Group, and I'll use this as an opportunity to also point out that Dr. Amy Snover, who's the director of the Climate Impacts Group, and they were a partner on the Regional Resilience Grant Project we'll be presenting in this series on Wednesday about this and some other climate-related work that the Climate Impacts Group does. They developed this tableau-based interactive sea level rise projection tool based on those tables to allow users to more sort of easily navigate the information that was embedded in those tables in a user-friendly and visually appealing way. This tool is also available at wacostlenetwork.com. So with that, I wanted to pass it off to Nicole Fagan to highlight what's the more important step, which is how do you take these tools that we built as part of this assessment and then translate them into use at community scales. Thank you. So I would like all of you to imagine being in a rowboat on the sea and then you imagine a huge storm is approaching. And now imagine you don't have any oars for that boat. That's really what's happening to our planners and resource managers who need to address coastal flooding and sea level rise. So my name is Nicole Fagan, as Ian told you, and I'm Coastal Management Specialist with Washington Sea Grant based at the University of Washington's College of Environment, where I help coastal planners and resource managers find solutions for complex coastal management issues such as coastal flooding and sea level rise. And as Ian mentioned, Washington Sea Grant funds and conduct marine research outreach and education throughout Washington state, and we support the health and sustainable use of our marine resources to improve the lives of people in Washington. And while I work with coastal planners and resource managers, we also work directly with a host of other constituents that range from fishermen to legislators to tribal communities and educators. So how do we get to implementation? As Ian talked about, we engaged in this four year effort, the Coastal Resilience Project, with four different tasks, which Ian talked about was the sea level rise data developing more specific for Washington state, then working with state agencies to develop better planning and project funding for those purposes, also working with the local experience to help communities in the region identify their sea level rise need for planning and implementation, and then ultimately finding ways to share it with the goal of rapidly increasing the capacity in Washington state to address sea level rise. What I'm going to focus on is the local experience and those aspects of our work. And our goal with that aspect was to enhance the resilience of at least three Washington coastal communities through pilot change, through pilot projects. So we selected two communities to work with on this effort. One was Tacoma, which is really a very urban community with a port and a very significant linear coastal park. And then the other was Island County, which is really much more of a rural community. And there the focus was really on concerning how to address issues of concern of shoreline homeowners. Then our third community partner in this was actually a state program called the Estuarine and Salmon Restoration Program, ESRP, which is at the Washington Department of Fish and Wildlife. And ESRP, it provides funding and technical assistance to organizations who work to restore shoreline and near shore habitats critical to salmon and other species in Puget Sound. So we worked with ESRP along with our other two partners, Tacoma and Island County, to develop guidance on how to use the sea level rise data we've been talking about to determine how you site and you design, construct and maintain marine restoration projects in the region. And we use case studies to develop the guidance for local governments and others who are working in the field of restoration. And once the case, this example of a case study here is the Lekwe Island and Ziziba project that's in Snohomish County. So then working with Tacoma, we worked with several of their departments, the planning department, the public works department, and then also with Metro Parks Tacoma. And I'm gonna give two examples of working with Metro Parks. So the city had a beach park, Owen Beach, and it was really struggling. It was getting flooded. The infrastructure was crumbling. There was a need to do something and to make changes. And so the city had Metro Parks had taken on the improvement of the facility. But early on, they heard about the work we were doing with our resilience project and they approached us and they said, we think we really wanna try to figure out how to address sea level rise as part of this project. And so they invited us to sit down with Metro Parks and with their designer site works to determine what are the sea level rise issues and how can that be incorporated into designing this park? So Ian gave a presentation very much like what you heard from him already and talked about what the sea level rise projections would be. And we talked through then what the different aspects of the park would be, what are the different infrastructure, what were the implications? These lines you see drawn here are showing the different sea level rise impacts at different times in the future. And we extended these drawings out so that then they could start thinking about what are they actually designing? Then as a result of that, they were able to come up with a complete rework of the project. And now it's designed and it clearly indicates where sea level rise projections might be and the facilities that might be potentially impacted are being pushed way upland outside of what projections might be ranging up until the year 2019 for beyond. Then another project we worked with Tacoma was to evaluate sea level rise and impact along this master planning project that takes into consideration sea level rise, storm surge and wave events. And it was supposed to just be a visioning of this linear park. But then again, Metro Parks said, we want to take into consideration sea level rise. So as a part of all of this area circled is what we were looking at as part of their visioning. So again, first we met with the design team and with the city, with the design team, Methune and the Metro Parks to impart the details of sea level rise to get them to understand what are all of the projections, how to use them, how to use them for different time frames. We also engaged in an exercise on modeling the wave impacts for the site and an effort that would soon be conducted that is going to be conducted throughout the region to give us all better ideas of how storm and wave intersect with sea level rise impacts. Well, then Metro Parks engaged the community. And this is an exercise of a visioning project where they brought all the community together in a series of meetings. And what was incredible is that usual visioning projects just look at the transportation or the access or recreational use of a site. But in this case, they had the whole overlay of sea level rise and brought the community along to understand that for everything that they were interested in, they also had to be thinking about what sea level rise would be. So ultimately with the input from the public and the sea level rise information, Metro Parks is starting to implement it for this linear part and it will be taken into consideration sea level rise. So next was with Island County. And what there we engaged was a series of different types of exercises. And one in particular involved the planning department and issues related to implementation of their shoreline master program and the need for homeowners to have better guidance about what are their options. So the first thing we did was we sat down with the planning department, public works and even a member of their board of commissioner. We walked through all these sea level rises. You see there's Ian explaining how to use these projections and to understand so that everybody was on the same page and really having the same language to talk about. Then we used the sea level rise viewer that Noah's sea level rise viewer. And it's a great way to get people to immediately visualize impacts the slider on the left of your screen, showing feet, that can be changed. And you can use that to simulate what the different elevation gate might be of sea level. And then that can relate to different time frames. And with that starting to notice what are the flooding impacts in different parts of your community and the blue areas show those areas of flooding. And so we had folks working in the room looking at what the impacts were to their community specifically to start to then target what they wanted to address. So Island Community said they wanted to look at adaptation strategies to be made available to the property owners. And they picked three different community types they wanted to focus on. One is their historic beach communities. The second was what they call their canal communities. And the third are bluff communities all in Island County. So what we did is we helped them work through creating a set of recommendation strategies and tables by timeframe, looking at short-term, long mid-term and long-term and considering what can you do to either protect, accommodate or retreat and thinking about all of these within what works within these different time frames. And then we relied first upon the sea level rise timetables that we've been developed now for Island County so we could determine what would be most applicable for a data adaptation strategy within these different time frames. Then another thing that Island County wanted to do is develop a community-based coastal resilience planning guide. Now the big difference here is this is a planning guide that's by the community for the community rather than it being imposed by the planning department or the county coming and saying to it. Five steps into this approach. This is very similar to approaches that you will see in many adaptation planning programs except that this is designed to be totally accomplished at a local level by a neighborhood. So step one is you define what your planning issue is. Step two, you identify the community values and your vulnerable assets. Step three is you analyze and risk the risk and your thresholds for when you wanna take action. Step four is you develop and implement community resilience strategies. And then finally, step five is you monitor the outcomes to inform your future plans. So these are projects. Both of these are ways in which Island County planners are setting themselves up to provide more resources for the shoreline homeowners based on all of the information we started with and the data to get them started. So big question is so how do you get these tools to these decision makers? So once you have the science, like Ian talked about the foundation, it's really foundation and it gets to where people can use it and they'd be emissaries to the broader community. So in order to do this, we held over 20 workshops. We're probably able to touch at least 300 people with this information. And then afterwards, we sent out survey to all the participants in the workshops. And we said, and this is about six months afterwards. And we said, in response to are you using the tools and the information we provided at our workshop, we had a 70% response rate of yes, we are using it, which tells us that this is, we're getting the information out there. And it's our priority to really focus on getting the right information so people can be using it. So through the collaborative efforts of Washington Sea Grant and our partners at Climate Impact Group, Department of Ecology and others, we are helping to put those oars back on the robots for the people of Washington state. Thank you. Thanks very much, Ian and Nicole, that was great. Sorry to audience, our audience, there's a sort of that mad dash to unmute and turn the video back on. So apologies for that little bit of dead air there. But that was a really excellent set of presentations. I love those photos of the community engagement. And to me that's a great evidence that what you're doing is impactful and it's meaningful for the communities you're working with. So thanks very much. So one of our innovations with these shorter format briefings is this idea of co-moderating. And so I'm gonna turn it over to my colleague, but before I do, we still have an opportunity for you to submit questions. You can submit them by following us on Twitter at EESI online or by emailing us at EESI at EESI online. But let me turn it over to my colleague, Amber Todorov. She's a policy associate with EESI coming up on her one year anniversary with us. So I'm actually more junior than she is, I believe, than around since October. Amber, why don't you take it away and let's get the Q&A started. Thanks. Great, thank you, Dan. And thank you both, Nicole and Ian, so much. This was a really interesting presentation and really great work that you guys are doing. So thanks again. So this first question's for Nicole. You started off with three kind of project partners, community partners. Have you seen a lot of interest from other communities? And if so, what are kind of the biggest barriers to communities to start their own similar C level rise adaptation plans? So I'm gonna start back with Ian's survey that he started with saying back in 2014, surveying not only did we find out there was the gap, but another thing that the survey asked was who's doing anything about C level rise and not very many, very few people in the community were. And as we've been working through this project, what we've noticed is because of our work in part, but also because of a heightened awareness, a lot more communities are taking on the work of addressing C level rise in this region. So it's a combination of that there's a lot more awareness. So people are starting to be engaged and because of us reaching out. So when we hold those workshops, we held workshops and we had over 35, 40 jurisdictions, including numerous tribes attending those. And everybody who attends one of our workshops then becomes a more of an adversary for them to go back and do that kind of work. So amount of interest we sold out, our workshops were filled to capacity. And then in terms of what's next, so I think that what we've been doing and what Ian and his team identified as a barrier was really a starting point, which is having information and having the right information. So people were going to, is it one foot? Is it two feet? Should it be three feet? So that was a starting point of we needed better information. So that barrier, we're breaking that one down and then making the information available. Then after that is a lot of work at the local level and priorities and especially now priorities are going to be shifting dramatically. I think we're gonna be seeing an even more need to make the information available to make it possible for jurisdictions to be identifying what their priorities are, but recognizing that this is something we really don't have a lot of time to be holding off on. Great, thanks so much for that. This next question is kind of for Ian more on the data side. So it's great to see another example of NOAA's sea level rise viewer in action. Our Southeast briefing we held last month had a speaker featuring that work as well. So what, and it's got so many great capabilities and functions, but what are there, are there any layers or updates in the database that you would love to see that aren't already there or that are perhaps in the works? Yeah, so yeah, it's a great tool, something that we sort of take for granted now because it's been around for quite a while but it's really ambitious in its kind of scope and scale. So it is part of our workflow, especially for communities that don't have GIS capacity. It's a great way to start interacting with sea level rise projections and get a first look at your exposure at various magnitudes of sea level change. I think the things that I would put on my list of stuff that I would love to see would be, so recent updates, I think maybe a year or two ago, Noah started including links to projections within the viewer and even localized for some locations. So I'd like to see that built out a little bit, right? Some way that really anybody in a community in coastal, the coast of the United States would be able to have localized projections. The other thing that I think we've really struggled with is being able to use the viewer to understand your exposure to what we refer to as extreme water level events, right? So those events where people really notice coastal flooding where water's pushed really high because of the confluence of high tides and storm surge and then what those events look like as sea level rises. That's kind of something that takes a work around to get there in the sea level rise viewer but typically that's what you want to map, right? Because that's where we start to notice that's where we start to notice the impacts of sea level rises on those extremes. So we really have to figure out how to use a sea level rise to be able to visualize those kind of events. Great, thanks Ian, that's really interesting. We're coming up on time and I want to, so we've gotten some questions and there are two that I think are kind of related and so I'm gonna try to combine them to close us out here. A lot of what you discussed today, Ian and Nicole, involved communities, personal property, public property, shoreline property. What are the effects of your work on sort of other essential infrastructure, things like shipping terminals and what are the effects of your work on sort of habitats, whether it's aquatic habitats or shoreline habitats for animals. Are you undertaking similar work for sort of non-human interests as well? Yeah, I'll start on that, Nicole and then you can follow up if you want. So the answer is yes. For example, I have a project that I'm currently just kicking off that is focused on habitat sensitivity and Puget Sound in particular to sea level rise. So essentially trying to use our sea level rise projections to understand if and how habitats may respond to sea level rise. So it's a little bit of a different, I guess, translation. There's different information needs but certainly our interest is in understanding Washington state's vulnerability to sea level rise, writ large, not just impacts to homes but also impacts to infrastructure and impacts to habitat. So and I'm gonna add as to who were our constituents who came to the workshops and who we've worked with for one of our workshops or a couple of our workshops, we had Washington State Department of Transportation who has been very engaged in this work and even before we've been incorporating this. So they've been doing work, looking at the resilience of their local facilities. One of them is a major is their ferry system and where their ferries are located. So Washington's Department of Transportation is using now more specific information because we provided it to them with this data and they're engaged in all sorts of planning and design. Similarly, the ports, one of the presentations was the Port of Tacoma and they were engaged in all of our work in Tacoma. And in fact, the industrial area called the Tide Flats in Tacoma was one of the areas we focused on because they're going to be looking at how they're gonna deal with not just the specific facilities but access in and out of the facilities and the whole range of them. So once you've developed this kind of information, it's broad spread in terms of how it's used and that was part of the beauty of what we were doing is working both with a very urban environment and a very rural to address that. And that gets to our ports, that gets to our industry, that gets into our wastewater, gets to all of the infrastructure and everything is affected but you need the same kind of information as a sort of a starting point and then how you wanna apply it is what you get to do, you have the option to do. So that's the beauty of it all. Thanks so much, Nicole and thanks, Ian and thanks to those who are watching us on YouTube and submitting the questions, thanks for that. In fact, we are not gonna be able to get to all of the questions that have come in unfortunately so we'll try to save them and incorporate them in later presentations that we have this week. Thanks, Amber, for all your work this week. Thanks also to Omri and Ellen and Anna and the other Dan at ESI, Dan O'Brien. Thanks for everybody. It's a lot of work to put a whole data adaptation or excuse me, climate adaptation data week together but I couldn't think of a better way to get it started than to have great presentations from Ian and Nicole about the work that's being done out off the coast of Washington and on the coast of Washington. So thank you very much. A couple of quick reminders as we close out here more or less on time. First, this is new for us. It's off to a great start but we'd love to hear your feedback. Take a moment, if you would, to fill out our survey. Visit us at esi.org to sign up for our newsletter so you can stay in touch and keep up with everything that's coming up. Tomorrow at noon Eastern we have part two titled Assessing National Park Asset Flood Rest. Retreat, Adapt, Fortify. Same time and you can find the link and everything you need of course on the website. Thank you all. Go ahead and there. Happy Monday the 13th to everyone and hope to see you back here tomorrow. Thanks so much. Have a great day. Thank you.