Is it good practice to make an exception in these cases?

Asked

Viewed 1,329 times

26

I’m solving some object orientation exercises. One of the exercises asks to write a class that represents an airplane flight, containing the date, number and methods to check the status of seats.

Requests ask for a method ocupa that is responsible for taking a seat number between 1 and 100 and if you are free, occupy the seat (basically this would only arrow you as busy). The exercise asks to return true if the seat can be used and false if it is already occupied.

I don’t know if I like this approach very much. Actually, thinking about the method I don’t think it’s natural to return anything. That’s why I implemented it differently. If the seat can be occupied, everything went well and you don’t have to do anything. In case the seat is already occupied I’m launching a InvalidOperationException with an appropriate message.

Exercise also asks for a method proximoLivre able to find the number of the next seat free. In this case the exercise does not say what to do if there are no more free seats and then I am also launching a InvalidOperationException.

Are good practices in cases such as this to make exceptions? I was in doubt if exceptions should be used in cases like this too, or only to deal with errors even in the application.

oop exception

  • I think that returning TRUE/FALSE is more like when you are testing whether something can be done or not. In this your scenario could be a method canBeOccupied( $id ) that would return TRUE/FALSE. Whoever uses this method to verify will launch Exception.

1 answer

30


Good practice

First, it is a "good practice" to do what is right and not because something is good practice. And what is right depends on the situation. What people often call good practice is what is usually correct in most situations. The problem is that they end up thinking that something should always be used.

Your case

If it is an exercise and he asks to do something in a way, it would be good to do it the way he asks. There must be a reason for him to ask like this. Okay, you want to go further? Come on.

Making an exception in the first case, as far as I could make out, is a abuse of appeal.

Exceptions should be used for exceptional situations. This is a case you are using for flow control.

This method should clearly tell whether the operation was successful or not. No problem of race condition. There is no reason to prefer the use of the exception.

If the operation could create a race condition (where the result is dependent on a sequence or moment of uncontrollable events and there is an error if this order is not preserved) then it would be different.

In this case if the method operation was unsuccessful (the method failed to occupy), you use that information to send the message normally. Use a if to verify the situation.

Of course it may be correct to use an exception, but in what you explained it does not seem to be the case. If you explain it differently, if you can come up with a better argument to prefer the exception, then I can suggest something else. So I started with the question of good practice. Only the specific, well-defined situation can determine the way correct next.

In the second case it is initially clear to me that the method should return the seat number free so that this number can be used somewhere. It might not be that because I’m not all set out.

You have three options to inform that there is no free seat:

  • Choose a number indicating that, zero or a negative number for example. This form is not well seen because it confuses what you are doing. You are using the same return for two things (reporting correct information and reporting an error). But it is still an option (bad in this case).

  • Since the method does not ask to return anything, it may be specified somewhere that this value is available otherwise. Then return a bool letting you know if you have a free seat or not. Maybe the exercise left this with you to test you if you were going to make the right decision. It’s exactly like the first case.

  • Using a double return can also be the solution. That is, the return is actually a bool and you pass a variable as reference (out It is sufficient in C# if it is the language you are using. If you’re using Java, I’m sorry, you’ll have to create a class just to get it right) to get the seat number. In C# 7 it is also possible to use a tuple.

    See the TryParse() as an example. It is a method that was created in the same way precisely to solve this exact problem. And note that the TryParse() was created because the developers of . NET realized after the Parse original launched an exception to control flow, to govern a business rule. It was wrong.

Mechanisms X Business Rules

Normally exceptions must deal with mechanisms and not with business rules. Not everyone can see the difference between the mechanism and the business rule, especially when business rules are not about business businesses but businesses closer to the technology used.

I can assure you that the InvalidOperationException was not created for what you want. It is a mechanism exception and not a business rule.

Nor is it the best reason to avoid an exception, but she is extremely slow. Nothing bad when something exceptional happened. But it’s tragic for the normal stream of the program.

With the pardon of pun, throwing or capturing an exception should be an exception in the code. Use in the latter case, try to make your program flow properly without the use of exception. But also be sure to use it when the code really can enter an exceptional condition, something out of the ordinary, something that shouldn’t happen (other than something that just isn’t valid).

Additional information that can help you understand more about the subject.

Browser other questions tagged oop exception

You are not signed in. Login or sign up in order to post.