Join us and get access to thousands of tutorials and a community of expert Pythonistas.

Unlock This Lesson

This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Hint: You can adjust the default video playback speed in your account settings.
Hint: You can set the default subtitles language in your account settings.
Sorry! Looks like there’s an issue with video playback 🙁 This might be due to a temporary outage or because of a configuration issue with your browser. Please see our video player troubleshooting guide to resolve the issue.

Answer the Question

00:00 Yeah, this brings us to the actual refactoring part. So now we have the code in a shape that created an “aha!” moment for you. So you are saying in the former lesson, “So, okay, so now I understand a bit more what the issue here is.” So maybe you can walk us through your finding.

00:21 I think I understand the issue right now, but I’m not sure yet at this point. From reading the question and cleaning up the code a bit, I can see that this person wants to figure out to see exception messages of an exception that gets raised in the stack trace of the main() function.

00:38 So an exception is going to get raised somewhere in load_model(), and they want to be able to see when they run main(), basically.

00:45 This is my understanding of the question right now. Then by refactoring a bit from top down, basically from the main() function back into load_model(), we came to a point that it looks like they’re confusing two concepts of raising an exception and then also catching it, and they’re trying to do this at the same time, which will prevent the exception messages from bubbling up in the stack trace.

01:08 So with this understanding, I now can see also that there’s a lot of additional visual clutter by just talking about two different exceptions that this person is trying to raise and then catch.

01:18 I can just get rid of one of them

01:22 because it’s not really relevant for the question. So I’m just going to get rid of one. I’m going to say if source == target, raise this error, and then what I just mentioned before: you don’t want to mix these two concepts of actually raising and catching the exception.

01:37 So I will take out the try and except from here and move it into the main() function because this is where you’re probably going to want to catch this exception. Yeah. So I will say—oops—try to load the model,

01:56 and then if an exception occurs here, then you want to catch it. Well, actually we don’t need to. We can start by not catching it. Let’s do that first. Okay, yeah, to actually see what happens there.

02:09 I’m going to keep this code around because I think it’s going to help us for refactoring later, but for now, the person really just wants to raise the exception.

02:17 They don’t necessarily want to catch it at all, or at least they don’t want to catch it inside of load_model(), right? Yeah. So now, okay, we have load_model(). I will take it out just so that we have—we can see how visually clean we can make this example actually, right?

02:34 And so there you go. We also don’t really need supported anymore. So now we really just have a main() function and then a function that gets called from the main() function, and then some still cryptic X that’s being passed in there that seems like the stand for source, target, which we can refactor in a bit, too. If I run this now, I’m not going to have any issue because source does not equal target here, so we’re not raising the exception.

03:01 But in the situation where

03:05 these two are going to be the same—source and target have the same value, and I’m putting this into this dictionary that I created an on line 13—now if I call this main() function, then the error raises. We get the AssertionError("source and target shouldn't be the same"). And from my understanding, this answers the question that we had up here because now there is a exception that occurs in what he calls the sub-function load_model().

03:35 And we are calling load_model() in the main() function, but the error message that got raised inside of load_model() appears here.

03:45 Here you have the stack trace that happened by running main() basically. Yeah. So, this was basically the answer. So, you removed the tryexcept statements in load_model() so that the raise AssertionError actually is not catched in load_model(), and in main(), when you call load_model() and there is an error, it shows in the terminal that there is an AssertionError.

04:11 So later you might work with tryexcept in main(), but to summarize the answer to the question is get rid of the tryexcept blocks in the load_model() function.

04:28 # Remove the `try` ... `except` block in `load_model()`.

04:34 And then we could flesh it out a bit. So this is the how-to-do-it. Basically, this is our answer how to do it. And you said at the beginning, this is a how-can-I-do-it question, so this would be a quick and to-the-point answer to solve the issue that the person is facing. And then if you wanted to, like, why is this happening, just because we’re in an educational context here, because I would say something like, “These are two different concepts,” I guess. In general, if you catch an exception, it’s not going to get thrown, and it’s not going to appear in the stack trace.

05:02 That’s the point of catching exceptions. So if you catch your exception, it’s not going to bubble up, and it’s not going to be anywhere in the in the stack trace. Perfect. Okay, but let’s not stop here.

05:14 We also said that we want to do a little bit of refactoring. So in the next lesson, let’s get into the code again and see how we can improve the code itself.

Become a Member to join the conversation.