Why make use of Python exceptions using raise?

Question

For example:

class ListaUnica(object):
    def __init__(self, tipo):
        self.tipo = tipo
        self.lista = []
    def __len__(self):
        return len(self.lista)
    def __getitem__(self, p):
        return self.lista[p]
    def __iter__(self):
        return iter(self.lista)
    def indice_valido(self, i):
        return 0 <= i < len(self.lista)
    def verifica(self, elemento):
        if self.tipo != type(elemento):
            raise TypeError('Tipo inválido !')
    def pesquisa(self, elemento):
        self.verifica(elemento)
        try:
            return self.lista.index(elemento)
        except ValueError:
            return -1
    def adiciona(self, elemento):
        if self.pesquisa(elemento) == -1:
            self.lista.append(elemento)
    def remove(self, elemento):
        if self.pesquisa(elemento) != -1:
            self.lista.remove(elemento)

• Why climb an exception?
• The programmer should not do everything so that an exception does not occur?
• What is the use of climbing an exception?
• The exception not for the execution of the programme?
• So when it becomes necessary?

Answer 1

Why climb an exception?

This is identical to the last question, let’s contextualize things first.

The programmer should not do everything so that an exception does not occur?

Actually, no. The programmer must do everything to ensure that the program does not give an incorrect answer. The exceptions help with this scenario.

So, let’s think, for example, of a script that the system administrator runs manually to do a back-up. If this script stops with an execution, and you can read in the displayed message that the destination disk is full, this is much, much better than the script ending without an error message, but do not back up.

Now yes, as a rule, at some point in your program there should be a block of type "Try:...except:" that captures all possible exceptions, and presents a message appropriate for the user.

In the example I gave, from a script executed directly by the administrator, this is less important than, for example, on a Web system, where the user should be presented with a page like "an internal error occurred on the server, please contact the administrator"or in a game where the message "operation not performed: try again".

In none of these cases could it happen that the operation is not successful and the user is not informed.

Now, within a "Try: except:" block, depending on the nature of the operation and the exception, the program itself can make an attempt to repeat the operation. (For example, in a request to an external server that gives a timeout, the program can redo the request).

What is the use of climbing an exception?

The greatest utility is to "divert the code to another layer, where you have to worry about the error". That’s basically it: an exception can come out of several nested "if", multiple "for" and "return" from an arbitrary number of functions - up to a point in the code where it makes sense to report the error to the user, or to try an automatic correction.

Let’s take for example the language C, which has no exceptions. It agrees that when a function cannot fulfill its role - for example, it does not have enough memory, it has to return a predetermined value to indicate this error.

Now, let’s assume that I’m making a program that encodes music in MP3 - it has these functions in pesudo-code, one calling the other. I might then need the calls in that order (with more code in each function where the ...:

interagir_com_usuario() {
    codificar_musica();
}

codificar_musica(...) {
    ...
    ler_arquivo_original(...);
    ...
}

ler_arquivo_original(...) {
   ...
   reservar_memoria(...);
   ...
}

reservar_memoria(...) {
   ...
   malloc(xxx);
   ...
}

Now, if there’s not enough memory, it’s that last call to malloc that will return error. And our program will warn the user of this in the function "interagir_com_usuario". The code in a language without exception has to be:

#define ERRO -1

interagir_com_usuario() {
    sucesso = codificar_musica();
    if (sucesso == ERRO) {
        printf("Não foi possível copiar a música!");
    }
}

codificar_musica(...) {
    ...
    sucesso = ler_arquivo_original(...);
    if (sucesso == ERRO) {
        return ERRO
    }
    ...
}

ler_arquivo_original(...) {
    ...
    sucesso = reservar_memoria(...);
    if (sucesso == ERRO) {
        return ERRO
    }

   ...
}

reservar_memoria(...) {
    ...
    memoria = malloc(xxx);
    if (memoria == NULL) {
        return ERRO
    }

   ...
}

In languages that support execution, it would be enough for the function "reservar_memoria" to raise an exception, and ready, a except in function interagir_com_usuario could treat this: no need for intermediate checks.

So just as the exception can be generated directly by the operating system, it could have been something that the innermost function detected, through an if... for example, if the original file did not exist, or if the destination directory is out of space, before to start coding. This sequence of error checking by return value becomes tedious, and error-prone.

The exception not for the execution of the programme?

No. The exception will return from multiple called functions until you find a block except corresponding. The program only for if there is no clause except in a more external role. Sometimes it’s not even the system programmer himself who needs to write this except. For example, if you are making code for the web with the Flask or Django framework, and there is an exception in your code, there is a except within the framework itself, which will generate an HTML page with a generic error message, generate the log with the exception data, and above all keep the program running to respond to the next page request.

So when it becomes necessary?

I believe that with the example of what is necessary to do when the language has no exception makes clear enough how it can be convenient.

But there are more things: an exception is not necessarily due to an error in the program - you can create a custom exception just in case you need to leave several nested functions.

An example that always happens in my code, is in game programming. When the character of the game dies, for example, this is detected in a check function, within the main loop of the game - in the middle of a bunch of other code. Then come other checks, updating the position of enemies, etc... However, when the character dies, I raise an exception with the command raise. And the except for it already closes the game scene, and goes back to the initial menu, ready to restart the stage. Generates much simpler code than doing a sequence of ifs to deal with the same case.

And finally, it is worth noting that the program that you took as an example, with a single two-line "check" function that raises or not an exception, is where the thing has little utility. Why anyway, whoever calls the method checks will always have to do it within a try, except when in fact, you might want to make a if. A more interesting design could be the method verifica from the example receive another parameter saying if an exception should be raised, or only return a False code if the check goes wrong:

def verifica(self, elemento, excecao=False):
    if self.tipo != type(elemento):
        if excecao:
            raise TypeError('Tipo inválido !')
        return False
    return True

And then ready, whoever wants that in the case of the verification fails to occur the exception calls this function with the parameter excecao=True. And in this case, the person may want this precisely to address the problem in another, higher-level function.