Rails has been guilty of this in many points of its life cycle, swallowing exceptions and turning them into things that are not helpful at all, and hide the actual problems. In the case of nil, it's probably more harm than good. Later, some code gets changed under there and starts throwing another error, but is masked by the fact that there's a rescue statement returning a harmless or harmful value. What invariably happens is that you do it because you ran into some error. Ideally in your error rescuing, you're rescuing just the errors you care about and generally defaulting through a broad rescue statement is going to be bad. Rescue just defaults to standard error, which is a very broad category and covers a lot of exceptions. One of the problems I have with rescue nil, is that when you use the statement modifier version of rescue you are not allowed to specify the kind of exception you want to rescue. Josh: Chuck, it sounds like your high school years were more interesting than mine. You want to know what's going on, so you know you have to evacuate the school or kill the program. But, when the stage catches fire, you don't want to turn off the fire alarm. So you set up this rescue to turn off the fire alarm, because you don't want to evacuate the school because some idiot is smoking in the bathroom. You've got some guy smoking in the bathroom, and it happens regularly. Now, you're either going to get the regular return value of that statement or you're going to get as a return statement the exception that it tried to raise.Ĭhuck: To me, I have this analogy. That's a nice little idiom for converting run time errors into return values, so if you want to get the error info back, but you just want to inspect it rather than raising it up the call chain, you can stick a rescue $bang at the end of the statement. But, I realized that there's actually at least one kind of cool use for rescue at the end of a statement, which is rescue $bang or rescue error info, if you're going to pull in the English library. It's pretty much the only thing that people use it for. For a while I thought that the rescue at the end of a statement was only an AntiPattern, because of this. You're giving it a nil back, and really it's an exception being masked that you didn't realize you were masking. God forbid that line might be 120 characters long. You can accidentally mask exceptions that you did not expect to mask, and it may not be obvious to the reader that you're doing that because that rescue nil could be all the way at the end of the line. Maybe we should get Avdi to tell us about why that's evil, since he's actually written a book on the topic.Īvdi: So, the reason that that's evil is because you can hide a lot of things with it. So, you just had some statement, and you tack a rescue nil onto the end of it, that was my initial reaction. My response to Jeremy's tweet was the rescue nil statement modifier. This week we're going to talk about things in Ruby that drive us crazy, as Chuck said, inspired by Jeremy's tweet. We will put the link to the page on our site where we're collecting questions, so feel free to give us questions you'd like us to ask Russ, and we'll talk about eloquent Ruby next week.Ĭhuck: If you have questions you can also tweet them to on Twitter. So, you have one more week on eloquent Ruby if you haven't finished it up yet. We were too, but we screwed up our scheduling. It's probably worth mentioning that for you who were expecting eloquent Ruby episode this week. James: Does that mean James is the most angry among us? I'm just asking. I think James had the longest list, so why don't we have you go first, James. So, we're going to talk about some of the stuff that people do in Ruby that drives us crazy. I'm almost here.Ĭhuck: This week we were chatting quite a while about what we wanted to do for a topic, and somebody pointed out this tweet by Jeremy McAnally, basically saying, "What's your least favorite Ruby AntiPattern?" We started talking about it, and we realized that we have a pretty good episode for this. This week on our panel we have Avdi Grimm.Ĭhuck: So, I'm back from the dead. James: And when you do that it makes me so damn mad! And if you do that I will come to your house and take your keyboard away.Ĭhuck: Hey everybody, and welcome to episode 32 of the Ruby Roads podcast. Then, I'll just sit here and listen to James rant for an hour. Any time that you've run into this horrible roomy thing that scared the crap out of you, right?Ĭhuck: There are lists of pet peeves, then there's James's master list. Can we do a coherent episode on that without prep for it? Josh: Ruby AntiPatterns should be class variables.Ĭhuck: I think my favorite is that you have a constant, which generally implies that it's constant and then you can go in and define constant. James: I don't really think that's really Ruby AntiPatterns.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |