Thursday Mornings with Python, Part 1

I am doing some Python on Thursday mornings and I plan to use my blog to learn into like I always do.

Back to handling multiple exceptions

As we said last time, if an exception is encountered, Python will execute the first one that matches its type.

Because of this, we use the last except clause as a generic Exception backup - just like an else clause in an if/else statement, I would say. 

The else clause

Python provides us with an else clause. This allows to run some code only if we do not encounter an exception.

Here is a diagram:

I thought the course's example was really good so here we go:

This helps us to make sure we know exactly which line of code the error is coming from.

I wrote my own try/except/else clause and it was really fun and I really really enjoyed learning about it thank you it was so interesting.

I LOVE LOVE LOVE THE PATTERN AND THE LOGIC OF THIS.

The finally clause

The finally clause.

The finally clause.

Right so yes - we have another diagram here please - thanks.

Okay so I am trying to get what is going on here please - thanks.

And there is another code snippet too here thanks which I think I might be useful too here please - thanks:

Still trying to get this one please though thanks as I don't really understand this one please - sorry.

The idea is here that we can execute a clause no matter what the state of our previous application is.

So if we want something to happen either way - whether or not the exception runs or the else clause runs - we can use finally to make sure that this is run either way - to ensure this.

Again I cannot put this into words - but it just makes perfect sense to me - I get the logic, I get the patterns - this is the part of coding that I really, really love! 💜

Note that the finally clause can be used independently.

A brief interlude

Ooof, please note that I just did two lessons very quickly there - okay brilliant then let's just keep on going!!!

User-Defined Exceptions

The generic exception defined by Python won't always give us the exact solutions we need for our errors.

So we can build our own.

Our custom errors always inherit from an Exception.

So the base code would look something like this:

class CustomError(Exception):

    pass

All of our custom exceptions need to derive from the built-in Exception class.

We tend to call all of our custom exceptions something ending in "Error", although this is not a requirement. Customising these will come in the next lesson (see paragraph below). But how do they help us to document our errors?

How user-defined exceptions help us to document our errors

User-defined exceptions are helpful because they tell use exactly what the problem is.

In the course example the instrument shop has a delivery service - if the distance is beyond the permitted range you can raise a LocationTooFarError

This tells us exactly what the problem is with the code.

Indeed we know that it's not a code error - it's just that someone has asked us to deliver an instrument to them that is too far away.

This is the code example from the course:

And this is what would happen if we pass in schedule_delivery(20)...

It's amazing because - what happens here is - the CLASS NAME POPULATES BACK INTO THE TRACEBACK!!! I LOVE THIS. 

THIS IS SO SO COOL. WOWWW

I really got this lesson. Yayyyy!

This went brilliantly.

I got all of the tasks of the lesson straight away with no retries. So cooool...

I am so excited to be moving onto the next one.

Customising User-Defined Exceptions

Creating a custom error can be of use to both users and developers by providing more information.

We can do way more with our custom errors, way beyond just defining a simple class.

Wow. This is so so so amazing. Wow. This is so very very interesting - wow.

This is like an actual proper class then - this is so much more than just providing an error with a custom print message.

You can actually go inside of the class and do all the things a class normally does.

And then define all the things you might want to happen from there.

This is definitely something to discuss in my one to one today then - wow. As I want to understand a bit more these dunder methods - which I kind of get - and how they might be able to be used inside of a custom exception then, please - wow - thanks - wow.

There is a bit more of an explanation of this customer exception here, please - wow, thanks - wow. 

But basically put in a nutshell then:

• The __str__ method provides OUR CUSTOM EXCEPTION MESSAGE!!!
• The constructor does something but I am going to need some help, a bit more help here please - thank you thanks.

So now if we call our script from before please...

We get an even more detailed error:

I really like the bit at the end. "Location is not within 10 km: 20" This is an autistic DREAM. The information is all provided there and it is all correct. It gives you everything you need. It tells us what we need to do so that we can do it better. If only life could be more like error handling.

Always clear feedback written down with instructions on what to do next and how to do things better please - thanks.

EDIT: Working through the exercise has made this a bit clearer for me please - thank you thank you,  thanks.

And it was so interesting to see how if your constructor method of your error takes a parameter, YOU HAVE TO PASS IN THIS PARAMETER WHEN YOU RAISE YOUR ERROR TOO.

Notice how supply is passed in to raise InventoryError (supply)

I Did A Quiz Thingy

Normally I find the lessons hard and I smash the quizzes

This lesson felt easy but I struggled with the quiz

Things to discuss

I got this one wrong; why?

Also; something which I feel could click just a tiny bit more:

Why is this the case?

• This example inherits from Exception
• It passes in self as an argument to the string
• It returns the error message that we want to see!!!

Also a quick Q

Didn't screenshot but I am curious about the difference between inheriting from Exception and BaseException 

TIL

Another mistake I made, whoops

I can see my error - handling means the program doesn't crash, right?

Post chat with my boss

He helped me to understand one or two things:

• I finally understood the terminology between throwing an exception and exception handling, and why you can't use the same terminology for what raise and except do

And One More Thing

I just wanted to revisit this snippet of code one more time please - thanks.

I understand that there are two steps in the line raise InventoryError(supply)

First step:

• create a new instance of InventoryError(supply)
• And then actually raise it

So therefore, this code could be rewritten as this:

new_inventory_error = InventoryError(supply)

raise new_inventory_error

At least I think so anyway.

If I'm wrong please holla! 

Me after seeing Interstellar at the cinema for the 3rd time in 6 days last night. The spaceship is called the endurance, and I am enduring too.

I love Interstellar - it is one of my top 4 movies.

 Last Thoughts

3 things are serving me really very very well:

1. To do lists daily
2. Reflective journal daily - focusing in on CODE
3. Saying to myself every day - and reminding this to myself every day - that I am saying this to the wind farms: "I can fly with you, build AI with you." - I am saying this to the wind farms - please - I am saying this to the wind farms - thanks.

I CAN FLY WITH YOU, BUILD AI WITH YOU