Coding Blocks - Clean Code – Error Handling

Episode Date: December 28, 2016

This week, we continue our Clean Code discussion as we dive into the joys and pains of error handing.

All right, so before we get started, there's something very important we need to know. Hey, why did the programmer quit his job? I feel like this is a rhetorical question. I already forgot the answer. Because he didn't get a raise. Okay. A raise. A raise.

A-R-R-A-Y-S. Arrays. That's perfect. All right. So here we go. I feel like I failed that. I totally feel like I failed that. Five.

Off to a great start. Four. Three. You're listening to coding blocks episode 52, subscribe to us and leave us a review on iTunes, Stitcher and more using your favorite podcast app. This is the acting box on that. We can find show notes,

examples, discussion, and more. Send your feedback questions and rants to comments at coding blocks. Follow us on Twitter at coding blocks or head to www.codingblocks.net and find all our social links at the top of the page. And we forgot to add this. Also, check out our Slack channel at codingblocks.net slash slack. And with that, welcome to CodingBlocks. I'm Alan Underwood. I'm Joe Zack. And I'm Michael Outlaw. All right. So let's get on to the podcast news.

All right, we're done. Yep. We're going to try and keep a little shorter here. We got some feedback about it. So we appreciate you guys letting us know what you think. And so we can keep working in better. So starting it off, we got some iTunes reviews. Oh, geez. So big thanks to Matt Zguba, Sforth4, ScottM98765431, and Bill Hefty.

Wow, you even did that without saying the two. That was impressive. All right, so our Stitcher reviews, we have Skokin, some guy from KC. It was a little bit different than that, but we're trying to keep this PG. Mr. Bonnie, Ian B, this pg um mr bonnie uh ian b mr bonnie ian b and hippopotamonstrasequipped something like that all right yes so good stuff

all right and uh as always you can find the full show notes at codingblocks.net slash episode 52. And big news this month for us, we hit 1 million podcast downloads, which is a really big number. And, you know, makes us feel really good. So just wanted to say a big thank you to us. That's a big part. Thanks to you guys for putting up with us and hitting those reviews. Yeah, man, that, that truly is crazy. We started almost exactly three years ago. So yeah, man, big, big deal for us. So thank you for coming along for the ride. It's awesome. And so now we've got our winners for, or our winner for episode fifties, a copy of clean code. And that is, and I'm sorry if I mispronounce your name here, it's Vaseline Vasilev. So congratulations. We'll be contacting you to get your information so that

we can send out your copy of clean code. And thank you for commenting on the episode. And for anybody else who wants to win a copy of clean code, I know that we're going through it, you know, come up here and leave a comment on this particular episode, episode 52 and get entered for your chance to win that book. Yeah. And actually, um, we have a Vassalens address because we sent him stickers for being on the mailing list. Oh, excellent. So we won't be contacting you. We'll just be sending it your way. We lied. Surprise. Guess what you're going to get in the mail. Right. And Hey,

speaking of getting things in the mail, how would you like to get some coding box stickers? Stickers are amazing. Everybody loves stickers except for Alan, but yeah, totally send us a self addressed stamped envelope. You can visit coding blocks.net slash swag and find out the information there to send

us your stamped envelope and we will send you back some amazing stickers. Yeah. Hey, wait, did we not? We're not going to mention the O'Reilly discount. Is that still going on? Yeah, we have one of those. Yep. Say 50% off most print books and 40% off

most e-books. there's a coupon code on the right hand side or the bottom of our website depending on if you're on a cell phone or not and if you just go there click that link enter that code and you can save some bucks yep and for any chances to win other stuff that we randomly get to give away to all you guys make sure that you join our mailing list just head up to codingblocks.net and we actually have like a little name and email thing there on the side. Join us. We don't spam. Actually, we seldom send anything

at all, but when we do, it's really good. Yeah, we're like the opposite of spam. So whatever that would be called, like when you sign up for a mailing list and you never get a mail from them, that's what we are. Yeah. Yeah. So we're the best one to join. So we don't send spam we send

like fine pork chops in the mail we're helping you obtain your inbox zero uh dedication there by just not sending you anything yeah we're good at it yep and before we hop into the topic um how's how's the sound in we uh got some fantastic help from aztec uh on on this template here so hopefully the audio is sounding really great and consistent and we're going to keep it that way instead of messing with stuff every time because it should be just perfect now so uh i don't know thank you aztec and hope you guys are enjoying was it aztec or aztec? I thought it was AZE. Yeah, anyways. It was AZT however you would say

that. Maybe that's why it never shows up properly in Slack for me. I'm always typing it wrong. Awesome. Well, thank you. All right. So this time we're continuing on with clean code and we're talking about error handling. And since the book is mostly focused on Java, I think it's fair to say that it's mostly focused on exception handling specifically.

But I think either way you call it, it's probably fine. Well, that's interesting. I didn't even think about the difference there. But yeah, totally. Yeah, it kind of tripped me up a little bit. But, you know, I mean, if you're, I guess if you're working in something like JavaScript or Ruby or something, I still kind of think of it as exceptions. So it's kind of interesting. Error to me just means something bad happened. But exceptions are a little bit different in my mind. I don't know about you guys.

I always thought they were bad, but they were trappable bad. Yeah. So that's good that we're talking about it tonight. Yep. That's good that we're talking about it tonight. Yep. First off, we should mention that although we frequently talk about Bob Martin writing this book, this particular chapter was actually written by Michael Feathers, who wrote Working Effectively

with Legacy Code. So we'll have a link to that in the show notes. Excellent. Alright, so let's go ahead and jump into it. There was a statement there at the very beginning that I really liked. And it was a fairly short chapter, which most of them have been, and we've somehow managed to make them not short. But the thing that they said that I really liked was error handling is important

and is needed, but if it obscures logic, it's being done wrong. Yeah, there it is. Um, so Joe, Joe was showing how thin the chapter was, right? Yeah. So we're doing video again, this time, hopefully it will actually turn out well, last time we scrapped it. Uh, so, so if anybody wants to go up on YouTube or Channel 9, hopefully we'll be up there here pretty soon. But just a little side thing. But yeah, I thought that was so important is error handling is needed, right? Exception handling is needed. But if it really confuses what the program is supposed to be doing,

then you're definitely not doing it right. And so that's what we're going to be talking about is how to do it right. Yeah, I like that. No, I'm sorry. Go ahead. I was going to say, what do you think the best way to visualize doing it wrong might be? Like if you quickly had to think of it. I've seen code with a ton of catches afterwards.

And I don't necessarily know that that's wrong, but it feels wrong. And it's like the first thing in my mind kind of jumped to. I think it's good to probably handle all the different things that can go wrong, but there's something about it that just seems a little stinky. I also, if you have a bunch of it mixed in with your business logic or the flow to where you can't actually see the flow, then, then you've definitely gone somewhere that you shouldn't be because now nobody can look at it and reason about it. Right. I'll take those. I was kind of thinking of the example and, uh, he talks about this later in the chapter, but, uh,

if you have to make your call and then you're immediately, uh, checking the results of the call so that you can know like, Oh, something bad happened. Okay. Let me bubble up a message back out to some caller method. Okay. Nothing bad happened. Okay. I can continue on. And especially if you have that baked several times in your method, because maybe you're already not following one of the previous chapters about short methods, then that would be an example of, uh, you know, it being done wrong. Well, that was a direct result of this next bullet point that we have, which

was if you're using return codes as opposed to exceptions, that's how you get into that nastiness because if you have like old, it's not as big a deal nowadays if you're dealing with like a Java or C Sharp or any of that because it actually has exceptions

that you can throw, right? Like you can create your own custom exceptions. But in the old days when you had to use return code, you guys ever remember writing any code for like credit card processes? Yeah. Like there was no exception that was thrown. You got some sort of return code that you had to go look up. And that's exactly what he was saying. The problem with the return codes is after you called that method, you had to immediately say if the return code wasn't zero and it was one or two or three or four or five, then, you know, do something. And so that instead of having a nice try and then a catch block down at the bottom, you're having to do all this mixed in stuff that really has nothing to do with your business flow,

but it's just, Hey, did something go wrong? Okay. Let me check it all real quick before I actually get into my business flow. So it's a direct hey, did something go wrong? Okay, let me check it all real quick before I actually get into my business flow. So it's a direct result of having return codes. Yeah, and the nice thing about something like C-sharp and throwing formal exceptions as kind of a standard is that I can just go ahead and say, do the thing, do the thing, do the thing. And if something goes wrong somewhere along the lines, it's going to throw, it's going to abort. And as long as I take care of that somewhere, I can deal with that somewhere outside of the actual logic process. So I don't have to have an if around every line. But you know, who's kind of taking a step back, at least from a little bit that I've seen of it, Go, the Go language, it supports multiple return types. So it's common to return an error type

with your function. And so the next line ends up being an error check. So you say, you know, OS dot open, and it gives you a file pointer, as well as an error, then your next line is if the error is not nil, and continue. Oh, that's interesting. So as opposed to like, in some cases, where you might return an object that might have an error attached to it, it just automatically has it is what you're saying. Right, so it means you kind of have to check it because you can't assume that if it failed that it kind of borked out. Interesting.

Leveling to some examples in the show notes? The only thing about the return codes, though, they kind of threw me off here. And maybe this was because just recently I had to do some work with this where have you ever had to do any kind of command line programming where, you know, more often than not it be at a command line or something else that might be

executing that command. It's going to look for zero for success and anything other than zero is failure. Right. Right. So that's the only time I was like, ah, do you want to throw an exception and just kill the whole app because of

that? Like, I feel like that's not the point that he's trying to make here. So I feel like that's a, I feel like that's a special case of error handling, which is not, I, at least I think that's not what he means when he's talking about like

using exceptions versus return codes or yeah, return codes. Well, in that case, what you're saying wouldn't be absolutely terrible, right? Cause you'd make a call to a method and if it returned you back zero, you just go on about your business, right? Like you'd say, Hey, if return code was zero, then just keep going. But what he was saying is the problem is if you have to, if you have to check all those status codes that came back. So let's say that it could have returned to 10 or 100 or 1,000 or whatever. If you have a bunch of that if logic right after you called that method, then you've muddied your waters. So agreed, you probably don't want it to blow up your app. But in most console applications, well, I guess I'm thinking like the more outer layer.

And honestly, you know, now, now I'm saying, I'm like, Oh, you know what? I should actually like write a test for this and see what it does. Because I'm thinking like, if you were to write just a simple, uh, console app that let's say just did a hello world, uh, return zero, right. Then that would mean success. But what if you hello world throw new exception, what's the error code that gets returned back uh if anything because we're in my case it was like sql agent that was spawning off a job and it needed to know if it was zero or non-zero that came back so like you were talking about like you know 10 1000 or whatever in this particular case it doesn't matter it's if it's non it's either zero or it's non-zero right right so that

wouldn't muddy up the logic too much so that was kind of what his point was though with that whole return code thing is if if you can avoid return codes and use exceptions then now you literally have your blocks that handle the various different pieces so your tribe block is your business flow right your logic your catch block is hey what went wrong just but it's all right there in one nice little tidy place. So that's, that's kind of where he went with it was a separation of concerns for your errors versus your, your logic code. Well, speaking of separation of concerns, um, I did find it interesting though, that in a previous chapter, uh, and I don't remember which

one it was, but I just remember for some reason there was like a cowboy drawn next to the paragraph in the book for some reason. But there was this comment that, you know, your function should do one thing and do it well. And error handling is, by the way, one thing, right? But in this chapter that wasn't like that, that concept was, uh, not carried forth in this one. So I didn't want to like, you know, as we're talking about this, I wanted to reiterate that, that idea that there, your error handling is the one thing. And so the error handling we're talking about here, cause all the, I guess where I'm trying to go with this is like all of the examples that we're going to talk about is going to be where you're handling the errors inside of the function as well as doing other stuff.

Right. And, but in this ideal world, your error handling is done somewhere else. I actually remember what you're referring to as well, because they even said you might just have a method that wraps the try around it. And it had to do with the, uh, keeping, keeping your function simple so that they read very easily. And I can't remember exactly which chapter that was,

but I actually remember reading that too. And I thought the same thing. I'm not really of a, Oh, you found it. Yes. Chapter three, do one thing. And it's a picture of a cowboy that told you cowboy. Yeah. I don't know why that, that was stuck in my mind,

but, but it's funny. Like, I don't, I'm not really of a strong opinion of it one way or the other, whether you keep the try catches in one place or whether you put it in another method that says, Hey, try this business flow. I kind of like to keep, I guess I am more of a strong opinion. I'd rather keep it. Like if I have a method that says, go do something, I'd rather have the try catch in there and the go do something rather than spin up another method that try catches your, your do something thing. I feel like that's just, that's, it's not really adding a ton of value as long as you're keeping your business flow in your tri, in your tri block and your, in your exception handling in your catch. I think that's, that's perfectly fine. Well, how about this? Um, we've got a method that we've got to try catch around

and we, you know, maybe return a nice string for the user, uh, in case of error, but now we're calling this a method from a batch process. And now we don't want a nice formatted error message. You know, we don't care about that. You know, we would prefer the thing just crashed. And now by having that catch around there, we are, we're making our software opinionated as to who's calling it. You know, we're, we're deciding for our callers, whether or not we just return a nice message or we let them see what really went wrong. In that case, couldn't you just rethrow it though? I mean, if, I mean, I guess that's a good point to back up, right? If you have a try catch, typically you're trying

to make sure things don't just blow up. And if they do blow up, you at least want to be able to log it somehow or somewhere. Right. So it's take action or might be the action, right? You want to take action. So, so really like what they said, I mean, in this goes further ahead and we'll have to check it off here in a minute, but to the point that you're making, if it's a third party app, you almost, or a third party library, you almost want it to just surface that error, right? You don't want it to do anything to hide it from you. Um, well, maybe we'll come back to third parties, maybe, but I guess what my point is, if you were doing a try catch, he makes the point in, in this chapter that the whole point of the catch is to make sure that you have a state that you know about in your application. So the catch allows you to either gracefully continue

with that state that happened while it was doing the try, or you can take an action, like you said, when you hit that catch. So really that's what it's about. Now, if you want to log it, like if you do your catch to log it, you can always re-throw it, right? So yeah, I would say that if you're exposing some sort of API, you let people grab whatever the error is and do what they want with it. I mean, he makes this interesting point that I'd never thought about it like this, but he talks about starting your functions with

the try-catch-finally structure first, and then start writing the meat to your functions or whatever logic needed to be in each of those sections, because it would force you to think of it in terms of a transaction. So going back to what you were talking about with state with the catch is that if you were to write it that way, start, start with the try catch finally approach first, and then write your unit tests so that, uh, you're, you're, um, checking for those exceptions and catching, you know, testing for those exceptions being thrown, that you can try to better make sure that you're keeping the transaction in a way where you're rolling back as necessary whatever state might have to be undone.

So an interesting take from that too, though, and they only sort of hinted at it but the whole do your try catch finally first and then write the unit test and all that they were basically talking about tdd they were like hey go in and do this and then they said also when you write when you first implement your method force the exception that you're trying to catch that way you can know that you're actually to catch. That way you can know that you're actually hitting those, those cases along the way and then improve it so that it starts working afterwards. Which is why I found, found that so interesting though, because I've

never, my first unit tests have never been, Oh, let me catch the exception. Right. It's almost never that. Yeah. You're always checking for your good inputs, right? Or what your expected outputs are. I guess I'm more optimistic than they are. Yeah. So I'm normally going, I don't know, like if you guys test your stuff that way. No, I never have. But it was an interesting takeaway. Yeah.

Big bias towards a happy path for me. I think most programmers are that way. Like we're conditioned to think about making things work, not making things break. Right. But there's definitely an upside to thinking about, hey, what's going to happen if this does break, right? So yeah, I mean, I've never done it that way, but maybe I'll try it next year around. I kind of like the idea too.

You didn't really mention that, but if you start, like you're starting like a greenfield application, you have one big try catch and you kind of start from there. I kind of like the idea too you didn't really mention that but if you start like you're starting like a greenfield application you have one big try catch and you kind of start from there I kind of like that idea because not only are you thinking about the bad pass but also I feel like if you end up having one place that's catching the error in the beginning then you're less likely to do a bunch of little

catches throughout and I love throwing exceptions and I hate catching them so the less catches the better, in my opinion. Huh? Yeah. I mean, that was like one of the things, I guess, because I don't write try catches because I want the exceptions to just bubble up out of my code and into whoever is using

it. It depends on the use case for me. If it's something that somebody is ingesting, totally. I mean, maybe more often than not, uh, let's say more often than not, I let the exception go. Right. Yeah. I mean, it really depends, right? Like if you're in the middle of some sort of, uh, transaction that you're doing to where you're coordinating a bunch of stuff and something blows up, right. You want to get it back to a good state. So if something does die, you're going to try and roll some things back. Fair enough. Fair enough. If we're talking about like e-commerce situations,

then yeah, things like that. Right. Yeah. Yeah. I wasn't thinking of that kind of example when I was talking, but like if you write an API, totally, you don't want to trap that thing. You want to let the consumer of that know that, Hey, yo, something went wrong. You need to do something or, or you can do something if you want yeah so hey this this next section go ahead sorry sorry one last thing on there um one thing i wanted to point out is that we are kind of spoiled by c sharp because of the using clause because a lot of the stuff he's returning to about returning the state to the the um a consistent and good state after an error um we don't have to worry about so much of the using clauses because it takes care of things like

disposing of objects and cleaning up connections and file pointers and stuff like that it just takes care of it for us so we don't really have to think about that but without that back in the day you were writing a lot of tries and not so much for the catches but for the finalese so if something did go wrong you had to clean that stuff up or else you would end up you know eating up handles memory whatever yep great point So this next section, I don't know, like I literally, I don't think I'd ever heard of a checked exception at either of you guys. Well, this isn't something that C sharp has. So, so this is a Java. This is, this is a Java. I don't, and actually I don't know of another language that does this, where the method,

the method signature specifies the exception well actually other he actually said in the book that c sharp doesn't do it c plus plus doesn't do it like there's a lot of languages that don't do it yeah yeah i'm not thinking of another one that would do that but i guess so so go ahead and explain what it was. Cause you started. Well, I mean, it's just, it's just as the, so maybe you have a method signature, um, you know, so public int add, uh, and then in parentheses, int X comment, uh, Y comma, um, I'm sorry, uh,

close parentheses and then throws, uh throws argument exception, right? Or whatever it might be. Or no pointer exception, or like you could list a bunch of them. You could list a whole bunch. And so I feel fortunate that like any of my Java programming days, I was able to skip over all of that. Let's call it what it is. Crap. And, and I didn't have to worry about that because like, because that was a huge, that was actually like, you know, apparently a big debate in the Java community, at least according, according to this chapter. Right. So yeah, I'm unfortunate that I didn't have to deal with that. Not me, man. So when I was going to college around,

I don't know, late 90s, well, early 2000s, Java was really hit, it was hip back then. So that's what we're doing in all our classes. And I was an idiot and would do things like work in Notepad and have my little Java book there

and I would type starting from the top. And so I still have that boilerplate memorized and so i always remember doing like um you know the the the public void main string args and then throws io exception so i always remember doing that and i didn't know that you could just um catch the uh the base class exception i thought that every single method i would write that would call new things i would have to call out those exceptions that i could possibly catch because I would look at the documentation and type those guys out, like argument section, IO exception, all that. It was such a pain. And then once I found out that I could just catch exception, I was like, oh, thank you. Cause I wasn't doing

anything with that specific information anyway. You know, it was all just stuff that shouldn't happen because I was working on it. Well, here was the thing about it that killed me. So at least you were only catching one type of exception right so the thing that they went into here that is such a big deal and the reason why it really kind of sucks is it violates the open close principle so what they were saying is if you had something like way up here that was calling down to a method way down here all the for those who are listening he's got his hands way up high up here way down way down here, all the methods who are listening, he's got his hands way up high up here, way down, way down here. So the problem is, is every method in between those two and your stack somewhere,

they all had to do that same signature list. So if all of a sudden this lower level method that you were calling throws a new type of exception, you have to go back into every single class in between that and the one that was calling it and say throws and then add that new one. So it completely violates that open close principle. So if you change something down here, you have to touch everything that may even, you know, glance at it. Yeah. It's a total implementation leakage that happens. All the way to the public static void main, I mean, to the very top, the very starting point.

And that's because I didn't know about the exception. I would literally, I would be like, okay, now I'm doing a query. I get a SQL exception. Let me go plumb it up through every single method all the way to the top in Notepad. That's enough reason not to have done Java. If that was back in the day, that's crazy. That's enough reason not to have done Java. If that was back in

the day, like that, that's crazy. But I mean, so to be clear to everybody listening, you don't have to do that. Like Joe said a minute ago in Java, you don't have to do it. It was a thing that people were doing at one point in time, but it's not necessary. Um, so yeah. so fortunately that's a thing of the past yeah no doubt so this next one and i really like this one it's they called it context with exceptions what provide context provide yeah provide context with exceptions so so true most people say hey yeah you can just get the stack trace right that should be good enough oh yeah i, for the line number and where it came from, sure. But it doesn't say anything about intent. So basically the gist was, Hey, go in there. And if you get it, you know, try and add some context to it, add a message to the, to the error, to the exception that's being bubbled.

Yeah. And I see that a lot in C sharp where I'll be working on something and I'll get a bug and it'd be like a null reference exception. Like, oh my gosh. And so I think the good habit of going through and checking for nulls that are likely to happen for whatever reason, and I'll throw a more specific error than just letting it fail on its own with a null reference. Because those null references, especially in production code where you don't usually get the line numbers and whatnot, can be such a bear. Yeah, those are rough. And ironically, we be talking about knolls in a minute anyways but i don't know that i'm like uh my messages would live up to his standard here though mine wouldn't usually yeah i mean if i'm being honest with myself here i you know, I, I would provide, I would throw, you know, exception with some verbiage

there, but, um, and, but not to like, he literally says there was this line here where it said, uh, you know, each exception that you throw should provide enough context to determine the source and location, which I think you, you know, referenced a minute ago, I, mine don't include enough context to determine source and location. That's, that's like normally, normally for me to find the source and location, I take that string and I'm like searching my code. Like where did I take that again? Yeah, exactly. Well, I do that too, but I think this more applies to, if you're not using some sort of logging framework or something that you're going to get this information anyway. Um i know if i'm working in an environment where i know i'm not going to get like the method name and class name i will put that in the exception so i can narrow

down quickly especially if it's a bad message but for the most part yeah i end up just searching the code so i do have a question though so you said that like on a null reference type thing how exactly are you going to get any more context about it? Because like you said, those are usually very generic, but unless you're trying and catching around every single thing that you're, that you're, I think it's the message though, right?

The strong, you would include in the, uh, usually maybe there have been times when I get the null reference error and I'm like, Oh crap, I know what happened in this method and I'll take a look at the method because I won't have any crappy logs and I'll be looking, and I'm like, oh crap, I know what happened in this method. And I'll take a look at the method cause I won't have any crappy logs. And, uh, I'll be looking,

I'll be like, okay, it's either this one or this one. It's really amazing to me how few dependencies there really are at a lot of methods. And so it may seem like you'd be doing a ton of checks, but most methods, most methods only deal with like one, maybe two, um, things that can really be null because the other ones are generated or they're passed in from somewhere else that would have you know bumped into it or something so there's usually not at least my experience a whole lot to check for and i only end up doing the the strict null checks and throwing very specific things for things that are like um very high bandwidth or not bandwidth but more frameworky things i know that are reused a lot and that are

likely to get bad input um so if you've got like some sort of utility that sends email or um you know some sort of maybe even runs a query you know something like this and that's a great place for logging because you know that your thing that runs a query is going to get called in a thousand different places and so the chances of some of those being wrong are high so that's a good spot to do very specific checking whereas you, you know, something that gets called in a method once a week, eh. Okay, so I just wanted to clarify though, what you just said though sounded like

what you would do is you would check to see if a particular thing's null. And if it is, you would throw an exception. It wasn't like you were doing a try somewhere and there were several things that could have been null. Then you end up in the catch. No. Okay, that's what I was.

That's what I was getting at is because there's no way to actually identify, you know, what was actually no in this big try block up here. I got you. Okay. All right. Yeah.

If and throw. Okay. That makes a lot more sense. Okay. Cool. Um, yeah. All right.

Catch fire. Yep. All right. So what we've got next define exceptions in terms of how they are caught. Um, I don't remember the section at all. So this one that, I mean, the very first thing we have here is think about how the exception will be used. Um, so basically what they're getting at is they had an example in the book, and I don't remember exactly what it was, but it was something like an open port call. And if the open port call failed,

then it would have something like there was a connection failure or there was some sort of other. I can read it. Yeah, all right. So there were separate catches for if it was a device response failure, an ATM 1212 unlocked exception, or a GMX error. Yeah, so really the whole point was, if you know that a consumer is going to need that information, right?

Like if that device failure thing was it, then you know that somebody is going to need to be able to handle that a particular way, right? So as the person who's writing the API, sure, you might need to throw different types of exceptions for that. However, if you're somebody consuming the API, you don't necessarily need, like they show in that book that, you know, basically for every one of those exception types, they were just logging the error and then being like, all right, cool. Yeah. In fact, the same in the example, of course, this is a contrived example, but the log message was actually duplicated for a couple of the types.

So there was like subtle differences between it. I don't usually create a new exception class unless there's something very specific i need that for so like for example if there's some sort of metadata that's specific to the kind of code i'm doing there then i would you know create a new class there a new exception class inherit and maybe add a place to set that metadata just so i can kind of log it more specifically somewhere but for the most part no i i like just using the built-in ones, especially C sharp's got some really good ones, like argument exceptions.

And then just all sorts of like input out of bounds exceptions, like some really specific ones already for you. And so I like those. Yeah, I'm with you there. In fact, I was thinking about this because more often than not, I think I agree with you. I don't create custom exceptions. I try to, and maybe that's just

a factor of the framework that I, that I happen to work in the majority of the time. But yeah, more often than not, I try to reuse one of the existing exceptions because like, if I go hunting around, if you go look in the MSDN documentation for, uh, all of the classes, the exception classes that inherit from exception. Generally, I can find one that's like, oh, that's the one that meets the particular need. There are times where I'll create one, but honestly, I can't even really think like you said a good example of where like you want to have specific attributes

on that class and that's why you do it. But I don't even really have a good example. Yeah, I got a bad example okay but uh i like this isn't c sharp specific yeah i'm sure if you've ever dealt with uh like windows type stuff and you've seen an error message it's like user failed to authenticate or server does not exist or message was invalid or whatever and that's the code 808 like8. But which one is it? Is it all three? Is it just one of these? Like, what's happening?

Yeah, they could have definitely used a more specific one in that case, right? Yeah. So no ors and exception messages. Just have two different exceptions. Unless it is authentication, because you don't want to be like, oh, you entered the wrong username. Oh, okay, let me try a million more, right? No, no, no.

Don't do that. Well, yeah. I mean, in that example, though, you're describing the difference between a message that you would show on screen to a user versus a message that you would get back to a developer. That's a good point. That's a great point, actually. So, yeah.

So going um, yeah. So, uh, going in wrapping up these last little pieces of this one here that I thought were kind of interesting is in the case where he was talking about, you know, those three different catches that they had and they were basically doing the same logging in them. And I love this about what this guy said, that is a perfect case where you should create some sort of wrapper, right? That basically says, you know, if, if there's this type of exception, just create your own wrapper that says, all right, do a log and then be done with it. And then that way it's, it goes back to almost the facade pattern that we've talked about in the past, right? You just make a, like a third

party library, look a little bit better by adding your own wrapper around it? Well, I mean, specifically about third parties, uh, you kind of hinted at that earlier and, um, you know, he has this quote in the book, which I guess is true. I, I, I mean, I can't argue with it where he says wrapping third party, uh, you know, you want to wrap your third party APIs, um, because wrapping third party APIs is a best practice. And I'm like, yeah, I mean, I can't, I can't argue with that. Um, it kind of makes sense. Right. But then I was like, man, like, okay. So I could definitely think of like maybe some payment gateway kind of scenarios where that's been done as an example but then i was like well okay logging is one have you ever wrapped

log for net so that you wouldn't have a dependency of log for net baked throughout your application like yes like that's a beautiful example i'm actually working on a video right now for that very thing, because this is totally side tangent. But so one of the things that we've all struggled with, because we have a lot of projects that have a lot of dependencies and in our project, share other projects in our day job. Right. And so one of the big pains is when something updates its dependencies, you have to go through and update everything to use those same dependencies. It sucks, right? Like it's, it's painful. It takes a lot of time. You have to know everything about all the apps and their dependencies. There's a name for it. Dependency hell. But that's a perfect example. So I'm actually working on, on doing like a little video to put

up on our coding blocks, YouTube channel that is basically, let's take this problem and instead of having this project depend on log4net, let's create an interface that is a log interface. And then basically using like dependency injection or whatever, you can spin up whatever you want it to be, right? It could be log4net, it could be nlog, it could be any number of different things. But to your point, exactly. You wrap that thing so that your dependency is on the one thing and you only have to update that one thing. Yeah. And, and yeah, I mean, I'm bringing that up because as an example, um, because I know, like, I know I'm bad about it. I know, like, I know I have definitely been like, oh yeah, I need a, I need some logging

in here. Let me just, uh, new get log for net and we're done. Yep. And, and there's my logging source. Um, and it's, it's only, it only becomes painful when you, when you go down that path of, wait a second, I need to use this in four other places. Oh, and they're all using different versions of log for net. And now it's like, it's like man this sucks and and typically what you do is you'll be like okay let me update all these right well so this is where i kind of take well not issue but um i feel like well maybe did i save myself any trouble because in your case of you, this is going to get implementation specific here, but so you wrap, you create your own logging library, and we're going to call this the CodingBox logging library. So you have CodingBox logging library that has a dependency on Log4Net. And now you have your three other projects that are going to reference the CodingBox logging

library. But CodingBox logging library is going to bring with it a dependency on log for net. So each one of those things still has a dependency on log for net. Just now it's an implicit dependency because of this other project, right? So you're not getting rid of this DLL hell or dependency hell. You're just kind of like moving it around and creating this facade around it. That's still there, but you can manage it so much better, right? Because now when you go to update log for net,

there's one place to do it. And then it just, it all flows uphill from there. It depends. You have the one place, but if that coding blocks logging library that we talked about, if that's a new get package and all your other projects now have a NuGet package, then they all could have different versions of the coding box, logging library,

DLL, right? So yeah, you updated that one NuGet package, but now you got to update those. So it's the same thing as if you had updated all of them to the latest version of log for net anyways, because you're carrying them along. No,ency Hell is like a whole other thing. I really feel like we need to find... That's our homework, man. We need to find an amazing book on... And maybe... Okay, I tell you what.

If someone's listening to this, then I guarantee somebody knows a great resource because I can promise you I want to know it. Oh, dude, if you Google this stuff... Because Dependency Hell would be an awesome discussion to talk about. It's nonstop, man. Like, if you go out there and look for it, everybody runs into these problems. And they're painful.

And it's not getting any easier either, right? Like, even with.NET Core, as awesome as it is to be able to piece all your stuff together, if you think about it, it's the same type thing with NPM and all these, like when you start bringing all these things together, now you have tons of dependencies, right? In the past, you literally just said, all right, I want my sp.net site. And it just kind of gave you everything. Now you have to piecemeal it all together, which is just more room for more dependency problems over time. So it's not an easy problem to solve. There's no question, or maybe it is, and maybe we're all just doing it wrong. I guess my point is, is like, I know that

it sounds, it sounds ideal to wrap every third party, uh, as, as a best practice, but it seems impractical to take every nougGet package that you're going to get, wrap that in your own wrapper so that you could try to, whatever your reasons may be, maybe dependency hell might not even be your reason for it. He says here, this way you're not tied to a particular vendor's design choices, and you can define your API to, to, uh, to, you know, whatever your comfort is, uh, that uses that third party. Right. So, you know, whatever your reasons

are. Um, but it seems like in practice, it seems impractical to say you're going to do that, especially on something that's so common as some of the Apache projects that are out there, right? And think about this too. With now we're in a.NET Core world. So everything from a C Sharp, you know, a.NET project point of view is going to be some kind of NuGet package that you can upgrade independently of one another, right? Or at least that's the, you know, the kind of nougat package that you can upgrade independently of one another right that's or at least that's the you know the kind of the idea behind it right so you know could you honestly see yourself writing a third-party rapper around system no but no but but going back to one of our way back episodes and i don't remember which one it was. I wouldn't take the approach of

every new get that we do. We wrap, but it's almost like the whole, if else thing that the whole open close principle, right? If you have to go back and touch something like more than once or twice at that point, maybe that's the time where you say, you know what, this thing is starting to kind of crawl throughout my various different projects that all have to be referenced. Now I want to write a wrapper so that I can centralize the use of it because the new gets not centralized, right? Like when you're doing that, that's, that's part of the problem is now you pull in this other thing that hasn't been updated. That's where you start running into the issues.

Yeah. I mean, I guess my, my core thing here was like, this sounds like a great idea, but where do you draw the line? Cause you could easily go extreme. Like I said, with, with system, right. But that we can all agree is an extreme example. Nobody in their right mind would do that. So where do you draw the line of like, okay, well, you know, if it's part of the, if it's part of the framework that Microsoft provided, okay, fine. We won't wrap that because that's well used enough. Right. But log for net's pretty well used package as well. What about Newton soft and like JSON packages that are out there, right? Like these are common things that in production code more often than not, and I'm going to emphasis heavily on the more I don't see it getting wrapped yeah so i i get it and i i am i think i lean a

little bit more towards pushing your dependencies out towards the edges of the application than you guys are sounding however i have one big uh thing to bring up and that's uh we've been most talking about nougat and c-sharp but what about JavaScript? Are you going to wrap every single require? Like I got three require statements in a function, you know, right? Like the whole MPT and NPM ecosystem is built around these tiny little packages that you use tons of,

right? You, but you know what? I think the reason why it works there better than it does in C sharp, and maybe this is a lesson to be learned is those are more, um, contained, I guess. So like, for instance, if you bring in something that has a dependency in NPM, right. And you do it within a particular JS file, it'll just use it for that one JS file. Right. So even if it's a different version than maybe another JS file depends on, like, I think you can do stuff like that and it's not as damaging and C sharp. If you have, if you have

a new get package come in that has, you know, a dependency on log for net and it's a different version than what your main app uses, it'll just die. Now I think there are ways around it. Um, and I forget what it is like copy local and do things like that, but it just creates more problems in our strongly typed world than it does in the JS world. Well, I was thinking that where the problem might surface itself more in any kind of strongly typed link compiled language is the fact that it's compiled. Yeah.

So, you know, if you have these two external libraries that each use the same library but different versions of it, then at the linking stage, they're going to conflict because they're going to be like, well, okay, well, which one of these do you ask? I have these two dependencies that each require the same library but different versions of the same library. I don't know which one to link to.

That's not a thing in JavaScript. You just load the file up and it runs in the engine, right? I can't remember the last linking error I had in JavaScript. Oh, wait, never. Never had thing in JavaScript. You just load the file up and it runs in the engine, right? I can't remember the last linking error. I had a job. Oh wait, never, never had that in JavaScript. That's never had Joe. When you said you, when you were talking about, I just want to clarify for everybody else listening, because I think I understand what you're saying, but you said you like to push your dependencies out to the edge. So basically you mean you like having like a bunch of interfaces and everything everywhere, but then the stuff that's actually using it, like your implementation, that's where you try and get your dependencies.

Yeah, so things that like touch the database file system, things like logging, I want those to be touching as little of my code as possible. And I'd rather funnel stuff through a common method to take care of it. And that's just, it has got a couple of benefits, like making things more testable and whatnot. Like if I'm poking through, you know,

like log for net dependencies in every method to do some logging, then that's the kind of stuff that can be harder to test around. And logging is not such a big deal. But if I'm like, say, you know, like executing queries in every method, just straight up, you know, SQL command, run a query, that's really difficult to test without having, you know, a database and maintaining the data in the state and that all the time. So just in general, as general rule, I tried to keep dependencies as far away from my actual logic as I can. So that's interesting. I think that might also kind of round back to this exception thing that we're talking about is I know that like, it's almost a tendency to put like, if you're building

a library to put a logger in there, right? So that you can look at what's going on throughout. But maybe the answer is just to surface more exceptions, right? And then whatever's using that library, you can then look and see exactly what's going on there. I mean, does that sound about right? 12-factor app said to just write the standard

out in standard error. That's a different kind of thing. we're talking about libraries but yeah i guess my feeling on this though is that uh the the more common something is used the less likely i am to wrap it the you know so uh you know i said i don't wrap the log for net library right because that's like i mean that's that's an Apache one. It's heavily, heavily, heavily used, right? So maybe I should be. I think it depends on your usage, right? Well, but if it's something like some payment gateway that's, you know, they have that particular

processor has, you know, a thousand different companies, you know, e-commerce sites that are using its services. And so there's not really that many usages of it out there in the wild. Then I'm going to be more inclined to be like, yeah, this one I don't want to trust. Yeah. It's interesting. I mean, it's pragmatic. Yeah, it really is. It is. But I would say that more so than just than just, you know, how many users or how many usages there are out there, it's how you're using it internally as well. So like I said, if you've got 20 different projects at all, somewhat include other projects at the same time, then it almost makes sense to pull it out so that you have one place to mess with. So it's, uh, it's difficult. Like I said, if any, I would love to hear from some of our users or listeners to leave a comment on this episode.

And if you have any great resources, we'd love to hear about it. And if you do leave a comment, then bang, you're entered into the contest. You can get some clean code. And if you don't want it, you can give it to somebody else who needs to learn about clean code. And guess what? It's Christmas time, so you could just give it away. Yeah, totally. Well, maybe not by the time this episode comes out.

This episode will be after. Hey, but speaking of, so it's that time. It's time to beg. So, guys, seriously, thank you. Everybody who takes the time to write a review or send us an email or whatever. Thank you so very much. You don't even know how big it is in helping us reach a bigger audience and truly help other people.

Like that's what we want to do. We want to help people get better at coding and feel like they're a part of a community. And so if you haven't, please do go up to codingblocks.net slash review and leave us a review and help somebody else, you know, get into this and get passionate about programming and doing a good job at it. So, um, that's our one ask. Actually, we had another ask,

hold on a second. We have a link that we're going to put on this episode. Uh, and, and hopefully this will be out before the new year. Please go vote for us on this podcast award page. Um, we were listed on what's the simple programmer. Is that what it is? Yep. Uh, John's on mezz's simple programmer.com. He's also got a podcast and the contest is running until the 31st. Yep. So, um, you know, hopefully you're listening to this of December, right? Hopefully you're listening to this. We don't really ask for much. We asked for reviews and, and, and this is the other one. If you, if you would find it in your heart to go up there and click on our podcast and hit, you know, vote coding blocks is the name of it.

Um, but that would be awesome. That would be amazing. The link will be here and we've got it on Twitter. We'll probably put it on Facebook. We might even email blast it. So we're pretty excited to even be a part of it. So please do that. Yeah. I was trying to find that link but uh whatever we'll find it yeah we'll get it up there all right so it's time for my favorite set portion of the show survey says

all right so our last one i think it was rather confusing for some people based off some of the feedback i saw on slack what we were trying to describe so maybe we didn't do such a hot job of it but here was the question when you need to add a new oh here's the question. When you need to add new one-to-one columns to a SQL table, but they only apply to a subset of the data, do you add it to the table? No reason to break out a one-to-one relationship or to create a new table for it. Keep things nice and tight. Or three, developers shouldn't be modifying schema. Or four, SQL? Nobody does SQL anymore.

All right. So what do you think the options, what do you think the answer, the most widely, what's your choice? I'm going to say, so I'd venture to say that most of the guys who listen to this are probably, or gals, are probably developers, not SQL people or database people. So I'm going to say that they're going to say,

just add it to the same table, right? Just no reason to break out the one-to-one. I think that's what the overwhelming is going to be. And I'm going to go with, because this was a little bit confusing, I would say 30%. 30%. Okay. Add it to the table. No reason to break out a one-to-one relationship at 30 percent oh i didn't account for the laziness factor um well shoot that is easier isn't it i don't want to create a new table everyone's everyone's judging my table names i'm gonna say add it to the table uh with 34 percent okay and remember we play by price is right rules so i'm potentially gonna win With 34%. Okay. And remember, we play by Price is Right rules. So I'm potentially going to win regardless.

So you're both picking the same one, just different percentages. Yep. All right. And survey says you're both wrong. I'm sorry. Really? Yeah. No way, man. Developers shouldn't. Really? Yeah, no, I mean, developers

shouldn't modify schema. Yeah, you think, but no surprisingly, the most popular answer was created a new table for it. Really? Yeah. By what percentage? Forty three percent of the vote. That's impressive. Hey, guys, thanks for doing it right. Yeah, is it Like going back to the example that we talked about, like my example that I gave, I forget what your example was, but my example was a customer contact information for address. You wouldn't put address two in a separate table.

You'd have address one and address two or street one, street two in the same table or the same with phone number. You wouldn't have extension in a separate table. You would have area code, phone number, and extension all in the same table or the same with phone number. You wouldn't have extension in a separate table. You would have, you know, area code, phone number and extension all in the same table.

But more often than not extension and street two are going to be null. I think you should put it in a separate table. No, you don't. I'm seeing your tables. You wouldn't do it for that example. I think that's part of the problem with that, with that.

We, it's like we both gave different examples. They were both a little bit different. They both kind of had a different perspective. So it was kind of a hard one. So that survey was a little tricky to answer. Yeah, I'm trying to remember what your examples were. I did vehicles. And I was like, we've got one row is a car, one is a bicycle.

And now we need to add a column for the engine type. It doesn't apply to the bicycle. But I don't want to create a new table just for one you know engine type but now we need up you know exhaust or something some some other new column that doesn't apply or something that only applies to bicycles right yeah i mean that's that's a tough one i i think generally generally speaking if you can if it's if it's not something like extension because i agree that's that's kind of silly like you probably wouldn't break you can, if it's, if it's not something like extension, cause I agree, that's, that's kind of silly. Like you probably wouldn't break that out, but if it's something that literally is, you know, so custom that only a handful of records in a table are going to have it, then yeah, you should probably break it out into a sub table and

then modify a view that joins them, right? Like create a view that will do a left join on the, on the table so that you keep your storage clean, but then your access to the storage can be just as simple as you want it to be. So I don't know. Hey, that, that was a pretty good one. All right. So that brings up what our next survey is. So do you listen to anything while you code is our next survey. And here's your choices. Number one music, because I got to get my jam on or number two podcasts. How else do you think I'm listening to this or number three audio books, because the books are always better than the movie. That's true.

Uh, what am I at? Number four TV, because how else am I going to stay up to date on Westworld? And lastly, coming in at number five, the office background, because I'm actually paying attention to my cubicle neighbors and all of

their conversations. I am really curious on this one. I think music's going to win. It has to. Yeah. I think that or white noise. Yeah. That's kind of what the office background is,

right? The background. Yeah. Yeah. Unless these are like sounds of the ocean or something. Nah, man, you'd be asleep.

Come on. Nobody go to that. Yeah. We're trying to stay awake here, man. Right. Yeah. All right. to stay awake here, man. Right? Yeah.

All right. So moving back into it, our next one, this one I found kind of interesting. He calls it the special case pattern and I'm almost positive. That's the same thing as our, um, null object pattern that we used to call. So, so here's, here's what, here's what it basically is. So in the book, he had an example of there, there's a particular problem and he's saying that we don't want to use try catches to enforce business logic. And I totally agree with that. So this whole idea was, okay, say that you have an expense app and you say, um, you know, get meals and then dot get total. Well, if get meals is null, if there was no meals that came back from that, then you're going to get an

error. And then what he had was a catch there and said, okay, well, if, if obviously that was null, so then do get per diem dot get total. All right. And the problem is that's now breaking your business flow up from where it was in the try to now flowing it into the catch, which stinks. So the special case pattern was, okay, instead of returning back a null from that thing, just return a meal, an expense or a meal expense object and get total. If there were meals, then it would return back the meals version of that meal expense. If there weren't meals, then it would return back the per diem version of that, you know, just a subclass get total. And then that way, if I remember right, that was the null object pattern, right? Yep. What do you see me wondering over there?

I just, uh, I don't love the null object pattern because I feel like a lot of times you end up doing things like checking to see if it's the null object. Because if you click on, say, this one was about kind of expensing meals and per diem and that kind of stuff. If you end up doing something where you have this null object that has no dollar amount, no receipt or whatever attached to it, and it shows up in a UI somewhere in a database report as zero.

Someone clicks a good details and like everything's blank or it shows what there's like dummy meal, you know, it's just kind of weird. So I feel like the logic is still going to be there to say, if this is the dummy one, don't do it. And so why not, you know, why are you recreating null? Well, no, I mean, so that's not entirely true. So, and this is where I was kind of like shaking my head, but then as you were talking, I'm like, no, yeah, you're right. Because with the null object pattern, the, cause one of the, okay.

So one of the examples is, um, instead of returning back null, like, let's say you're supposed to return a list of something. And instead of returning back null, like let's say you're supposed to return a list of something. And instead of returning back null, you could just return back an empty list. And then that way your caller is safe to iterate on it. And there's no need to check for null. Right. I'm with you on the case of, you know, if you,

um, like visual studio magazine has a, has an example of using this where they, uh, they have to create a customer not found object. And you're checking to see like, Hey, uh, is the return type, a type of customer not found. I'm with you on that, that, that from a gross factor, like, Oh, that sucks that you had to do like this type checking, because then it's

like, well, why didn't you just say like, if not null, right. Um, that kind of feels the same way, but where I have done something like this is that maybe you have, it, it will have to implement, uh, the same, like either base class or interface, whatever, whatever that's going to be, right. It's going to have to be able to adhere to the same kind of, uh, contract. Right. So, um, what I have done in the past is my like null version of it or not found version or however you want to rephrase that is just like a like a benign do nothing version like you could call those same methods on it but nothing's going to happen so like if you are um you know so if you have some factory that returns back and so its default might return back this uh uh null version or not found version or benign version,

you know, you trying to execute on it, isn't going to like throw a bad result your way. Well, to, to address both things that you guys just said. So first Joe, I would agree. I wouldn't want to go to a page that had details of nothing. Right. But maybe your null object says this was a not found thing. Right that means your 404 page or or something so when it displays on the on the ui it doesn't look like you know oh i just clicked through on us to nothing no really it would be you'd basically have some default information and then it said yo this wasn't found um but to the empty list thing the problem with that is remember they're trying to enforce logic flow here, which

was get, get meals. So your empty, your empty thing would come back and give you a $0 amount, but you don't really want that because you want the per diem if the, if the, if they hadn't registered any meals, right? So, so the whole point was they were doing a try on something that would eventually give a null pointer error and then doing a catch and then saying do per diem, but you couldn't do the empty meal thing because then you're just going to zero value back when really you need to fill in the per diem. So that was the whole point. Let me tell you though,

if this were my job, I would never file any expenses. I would just click the per diem. So it's a, it's a broken. I do nothing and I get the money. What the heck? For a second, you kind of reminded me of fire marshal bill. Let me tell you something. Let me show you something. Yeah. Wow. That's going back. That's a few days. So I don't know. It was kind of interesting, but am I wrong?

Is that what it was called? The null object pattern? I could have sworn it was something like that. That's it. Okay. They were calling it a special case pattern. I think it's a slight twist on the null object. The null object was a little bit more specific, specifically for nulls. Yeah.

Yeah. I don't happen to do this. I guess I return Nulls. With lists, I definitely always return empty lists, but I don't really have a problem with Nulls, especially because I get so many of them. Some of them I just gave up. You've been beat into Nulling.

Well, that's a nice segue into our next section then, which is don't return Null, Joe. I feel like this chapter was written and directed straight to you. Oh, that's odd. It actually says to Joe Zach. Yep, totally. I mean, if you give me a null, I'm going to give you back a null. I mean, so I, I 1000% agree with what they said here. It junks up your code and it defers from what you're actually trying to do. If you're having a null check everything, you get lost in it, right?

You totally, it's just garbage. And typically it's half of your method. Like that, that stuff just drives me crazy. So I don't know, man, like I'm, I'm crazy so i i don't know man like i'm i'm definitely on board with don't return null throw an exception if if you expect there to be something throw an exception or or do the null object pattern like i prefer those nulls are gross they just tend to spread so the cases i'm kind of thinking of where it's like i take uh you know,

I've got a method that like operates on a user or something and it checks the status. Well, if there's crappy data in the database and it's got a nullable column and the status ID column is null, then, you know, I've got to do something, right? And it's not necessarily an error case. We just don't know the status. So I'm used to kind of thinking about checking nulls

and just not doing stuff. But maybe that's just wrong. Yeah, I can't help, but for some reason, as we're talking about this, I can't help, but think of one of my least favorite methods,

at least in the.net framework, which is string.is null or empty. I use that so much. I hate it white space and the oh yeah there's also is null or white space i'm like why aren't these like why isn't it all the same is null or white space or empty yeah white space does the uh empty one it does yeah i use this null or white space way too much. And again, it detracts from your algorithm, from what you're actually trying to accomplish. When you're having to check every single variable that came in, is this thing null? If it is,

okay, then I need to make it not null. If this is null, then I need to make it not. It's garbage. I mean, also, Joe brought up the case of the nullable columns in your uh database this makes me think about nullable types and then if you're doing nullable types then it's like oh uh if this dot has value then let me get dot value from that thing and it's like i mean now i guess with the uh what's the new operator called? The question mark dot? Yeah, I was trying to remember. I've been sitting here trying to remember. I can't remember the name of that operator.

Not null coalesce. Dang it. Whatever. I'm going to try to search for it while I ramble. The null conditional operator. Is that right? Question mark dot. That's really hard to Google for. It is.

It really is. It's hold on. I have it right here. Yes. No conditional. Um, let me paste it in. For some reason I was thinking that like,

uh, where's our chat? Reese Sharper calls it something different, though. There you go. I put it in our chat. You changed the name. You guys go take a look. Yeah, that's the same link that I found to Misty and you.

Yep. So, yeah, I mean, I don't know. It does make it a little bit less ugly to look at, but it still doesn't take away from the fact that you're literally focusing on data checking rather than doing something in your code. Unless you're using the null.

Whatever we said that thing was called. Yeah, the null object pattern. Or the null conditional operator. Although I could have sworn when C Sharp 6 was being announced, it was called something else. It might have been. We have that intro. Yeah, it definitely was.

I'm trying to find it right now. I know we did a whole podcast basically on it. Yeah. Yeah, I was like looking through the old podcast now. I'm like, wait, I know that we called that something else. Yeah. It was one of the things that we were the most excited about because we wouldn't have to do like something dot has value okay fine give me something dot

value but yeah yeah so um what did it say oh i here was something interesting so joe you said you like just keep passing them along, right? Yep. Because you're just used to them. They actually said in the chapter, if you're dealing with third party that returns nulls, consider the facade pattern and intercept and return an object. So they're basically saying do that special object pattern even for a third party, right? So that basically you're never having to check nulls,

which I like. I hate checking nulls. It drives me crazy when I do it, and I hate seeing it in code, even though I add to that code. So, yeah. Monadic null checking. Monadic null checking. Yeah, I saw that.

But I thought there was something else. But I did, if I could sidetrack for a moment, though it does take me back. So for those that haven't listened to episode 10, my very favorite poem is in that episode circle circle dot dot. Do you want me to read it? I would gladly read it. We could link to episode 10. I really love this one. Waka waka,

bang, splat, tick, tick, hash, carrot, quote, back,

tick, dollar, dollar, dash, bang, splat, equal at dollar, underscore,

percent, splat, waka, waka, tilde, number four, ampersand, bracket,

bracket, dot, dot, slash, vertical bar, curly bracket, comma, comma, crash. crash nice it's beautiful we're gonna have to have a link to episode 10 i forgot about that one man episode 10 has been a while back yeah man we recorded episode 10 that was uh may of 2014

we old now. Yeah. All right. So the next one that we're going to get into is we just talked about don't return, Noel. What's even worse? Don't pass, Noel. And I agree. I don't like seeing Noel's past into things.

What you got to say? I do stuff I don't like all the live long day. Oh, man. say i do stuff i don't like all i'll live long day oh man yeah but for those sorry i try not to propagate problems but i i don't know the null thing just doesn't bother me i guess i i know there's a like this is a often talked about thing on like reddit and hacker news and stuff and people talk about the the badness of nulls and stuff and And I just kind of, you know, see, no, because then the problem is now, like if you allow for nulls in your method,

then you have to check for this. Yep. I don't want to do that. I'm too lazy now. I will. So I'm just not going to check for it. And then I'm going to let a null exception, uh,

exception bubble up. I hate that. It happens to me yeah oh but but to joe's point i will i will give a little bit of credit where credits do when you're dealing with database objects that have been marshaled into you know a dto or something like you inevitably deal with them like there's really not a bunch of ways around it and you mean like in the case where you have nullable columns? Yeah. And then you have to make the decision which we talked about earlier

to a certain degree to where you start translating that data and then you start running into more problems, right? And it's even worse though because then the problem with talking about it for database, at least in a.NET world, is now you can't just say like, hey, does this equal null? No.

That would be too easy. You got to say, does this equal db null dot value? Which is garbage. Why? Why did they do that? It would have been so much better. But I will say, I think if you're not doing the straight ADO stuff and you're using something like Dapper or some sort of mapping library or entity framework,

it actually is null. You don't have to do the db null dot value stuff which is true which is nice like if you're having to do that then you probably need to look into another way um but but i do agree try not to pass null into things like i cannot stand that um and they're saying just don't allow the methods to take in null parameters which is is interesting. I kind of like it. But the problem is, is like they say, it's very hard to maintain because you have a nullable parameter. If you weren't thinking about it when you were writing your code, you probably forgot to do a null check and you're going to get an exception when you didn't want it. So, yeah, I mean, being able to not allow nulls on your uh the parameters being passed in is kind of dependent on what uh framework or language you're in though if you have the ability to put those

kind of asserts on the signature right i mean in c sharp you just get rid of the question mark on most of it unless it's like a string or something right and then you can't really do much of jack about it so uh so like an integer right that has to come in as an integer sure on on yeah on like the primitive types but if it's if it's reference types yeah you can't do anything about it at all yeah um so anyways that that uh that wraps up this one for the most part um we got any resources we like? I think so. We might have referenced. There's a certain book

that we have referenced once or twice. Help me out with the name, Joe. It was Clean Code, a Handbook of Agile Software Craftsmanship. That's the name of it. How could I forget that? Yep. And you can win a copy if you leave a comment on this episode.

Was I supposed to like, we're all showing up. Yes, we could all do that. My copies of that. We all have our copies. Oh, you know what? I should have just like hid here. Now you could look at that instead of my face in the camera. That's what I should have done this whole time.

He's a clean coder. That would have worked out so much better. So as we get through that, then I guess we're going to have to head into Alan's favorite portion of the show. It's at the tip of the week. Yes, sir.

All right. So Jay, what you got, you actually got one cause you left this blank for a while, didn't you? So this is kind of a derp moment for me. I was, I try to practice inbox.

What? I don't want to say I practice inbox zero because i have a large cycle so it's like i clean out my emails like every two three weeks and then i like take it down to zero and then the mess you know starts up again so i've got like a long you know i don't do this every day but um you know how gmail a while back they added those little tabs for like promotions and i think social like that was great yeah on the phone it doesn't show as as sorted for me, but Gmail's got those little tabs there, which has been really nice because I generally just go to social and the promotions and just

every once in a while just take them and either archive or delete them. And that's been great. So the other day I clicked and I was like, you know, I wonder if there's any more. And there are. I forget what they are now. Maybe we can take a quick peek while I'm talking. But I added a couple more boxes for updates and forums. So that was that was nice and just kind of brought up like

i'm looking at 40 emails in my updates right now and it's all stuff that i should you know go uh unsubscribe to but while i was doing that i was like you know what um i'm kind of an idiot like i bet gmail has pretty good support for filters, which is something I do extensively at work for things like Outlook, you know, CC. I've got all sorts of rules set up, and I maintain them like crazy. But for some reason, I guess, because I never had to worry about storage space

and the search was so good, I just never thought about filtering messages in Gmail. So now, if you click the More link in Gmail and go down to filter messages like these, you can have a selection and it'll actually does a pretty good job of kind of populating the boxes and saying, oh, emails from this or containing this subject or this too, whatever has these words and just really easy to do. And I can use it to more effectively manage my Gmail, which is even how I manage most

of my non Gmail mail. So how I manage most of my non-Gmail mail. That's my tip of the week. You guys and your zero inboxes. Yeah. That's malarkey. I've got like 14,000 in each one of my mailboxes. They're search engines. I think that's a new thing, though.

I've definitely heard a lot of people talking about 14,000 inbox. I mean, it really should be. I mean, it's a search engine. a new thing though uh i've definitely heard a lot of people talking about 14 000 inbox i mean it really should be i mean it's a search engine why i gotta mess with like trying to put stuff in folders i'm not good at it uh yeah although i'll tell you man i i deleted my social for a while there because usually i go through the twitter app i go through facebook you know and i like i look at the notifications there everyone's wow oh i fit sent me something she's like you didn't respond to that you know picture i sent you i was like um yeah i don't know i'm not really seeing it she's like yeah i sent it last week i was like oh you know i just cleaned my inboxes i deleted

everything in my social folder without looking at it that's i probably just deleted it it's like what oops uh i got in some trouble like what what other emails of mine have you been deleting and not reading? And I didn't know. That might've happened to me. My wife accuses me of reading everybody's email except hers. Yeah. So archive is generally a safer option. Yeah.

Sure. Excellent. So mine is only because I really started playing with it recently and it's awesome. Our Azure functions, like if you ever had like a little utility you wanted to write that would do something right, but you didn't really have a server to spin it up on, or you didn't want to have to go try and find some place to put it. Like, these are like the perfect answer to being able to do just about anything you want for, for dirt cheap. So like Azure functions allow you to code in JS. If you want, you can do it in C sharp. You can probably even do it in some other languages. I haven't looked into cause I haven't

cared to, but like the use case I was thinking about was, you know, going and getting some data and just shoving it somewhere or emailing it or, or, you know, whatever, like you can do just random things. Like if you had IOT devices or something, and you wanted to use like maybe some sort of queuing system or some sort of event bus, but you needed something to happen when that, when that event raised, you could just write an Azure function and have it do it. So like Azure functions is, is like this. And I'm sure they've been around a while and I'm sure I'm late to the party, but man, they're really cool. And you can, you can do tons of stuff. Like if you're doing C sharp, you can add new get packages to them so that you can work with it. Now it does have to be.net 4.6, uh, compatible to do that stuff. If you want to do node coding instead of C sharp,

you're free to do that, but you can have things like trigger HTTP events. So you call an HTTP thing. You can have it trigger based off other methods within the Azure cloud, but super cool stuff. If you haven't had a chance to mess with it we'll have a link there but um an awesome way to be able to do for dirt cheap just some really neat things with with utilities that you might have been thinking about doing you know um carl and jason mentioned some cool things on the ms dev show that you've been doing with it um particularly with the stats for their um the podcast so i I think it sounds really great. It's kind of, I like the idea of having like almost a scripty type thing, like the type

of thing I would normally do in a script, but that's out on the cloud and accessible for multiple locations. That's exactly what it is. Yeah, it's amazing. And you get your own URL. It even gives you like your own like folder where you can upload other DLLs and things. So you can even reference, you know, private DLLs and things. So you can even reference, you know, private DLLs if you need to, if you're doing the C sharp thing. Uh, I mean,

there's just a ton of uses. I will say getting used to the Azure portal takes, takes a little bit of time. It's done very well, but it's kind of overwhelming with the amount of stuff in there, but definitely give it a check. If you have like any idea for some little utility that you've been wanting to do, I would go play with it. And you can sign up for free on Azure for like $200 a month, or you get $200 free credit for your first month. If you sign up on Azure. So like chances of you hitting that, if you're just screwing around with things like Azure functions are so low that it's worth first month, first month. That's key, but it's worth playing with. Like, I mean, I would definitely go up there and mess with it. Yeah. They'll give you the first one for free. Yeah. All right. So

my tip is a visual studio tip. So if you like WebStorm or Adam, uh, or any of the IntelliJ or, you know, ReSharper family of IDEs, then you might be familiar with in WebStorm. If you wanted to open up a particular file, you can do like this fuzzy search. So you could do like a, I believe it's a command shift O or control shift O depending on your platform. And you could do like a, I believe it's a command shift O or control shift O, depending on your platform. And you could just start typing in the name and WebStorm or IntelliJ or whatever, PHP storm. It's doing like a search based on what you're typing in and showing you like, here's all the relevant files. And then you can click on that one. And Adam has a similar feature and it's a command P or control P depending on platform where you could do that same kind of thing. Start typing in your, uh,

portions of your file name and it starts refining the list to that. Right? So you, I found out you can do the same thing in visual studio and I don't know how long this has been here. So I'm calling this one, a visual studio, 2015 specific thing. because that's what I found it in. 2013 as well. Okay. I wasn't sure about that. So thank you for that clarification. But you can do control comma and you can start typing in the name of the file and it'll start refining the list and let you open that file from that little command window that it opens up. Why they picked comma, I'll never know. Yeah, I don't get that either, but it is extremely useful. Yeah, especially if you like to keep your hands on the keyboard

and just navigate to the next file. Um, without having to, you know, use your mouse to, you know, click on some open button or navigate a directory tree or switch to another tab, whatever.

Yeah. Yep. So it's handy. It's fun. Excellent. So let's call that a visual studio, 2013, 2015.

There it is. Tip of the week. Which hopefully everybody's moving up to 2015-2017 here soon. Hopefully. Yeah, hopefully. All right. I hope you've enjoyed this chapter seven of clean code error handling. Subscribe to us on iTunes, Stitch stitcher and more using your favorite

podcast app and be sure to give us a review if you haven't already we super duper duper duper appreciate it uh you can visit it us at www.codingblocks.net slash review to find handy links to the major platforms yep and definitely come check us out because if you go to codingblocks.net slash episode 52, you'll find our show notes, examples and discussions and much more. Yeah. And I don't know if we were, we remembered to mention this earlier, but, um, we did mention if you send us a self-addressed stamp envelope, but I don't know that we mentioned you can actually find that address at codingblocks.net slash swag.

Oh, good point. Good point. And there's some links to some other stuff too if you wanted a cool shirt or something. We have that. And so aside from that, send us your feedback, questions, and rants to the Slack channel because people there are awesome and much more

responsive and smarter than I am. And also, follow us on Twitter at CodingBlocks and head over to CodingBlocks.net for all sorts of stuff. Don't forget to leave a comment on this episode for your chance to win a copy

of Clean Code. Go check us out on YouTube because hopefully this video will work or Channel 9 because we're going to get it up there as well. So faces with audio. Here we go. I did two videos this week, too. I forgot.

Oh, nice. Yes. Oh, yeah. So go up to coding or coding blocks dot com or dot. Oh, geez. Coding blocks. Oh, wow. Alan coding blocks dot net slash YouTube or go to YouTube slash coding blocks. Wow. Alan coding blocks.net slash YouTube or go to YouTube slash coding blocks.

And you will get to see all the new stuff that Joe's been putting up, man. We need to get that.com. Don't we? Hey, uh, Alan, uh,

what's Dr. Dre's favorite search engine. We just talked about this like an hour, half ago, being, being, being, being, being, being, being, keep the head drinking. we just talked about this like an hour and a half ago for every joke I always want to respond denim denim denim oh yeah totally oh yeah totally

alright guys that's a wrap