Learn Elixir: Creating Error Systems for Debugging

Learn Elixir In 12 Weeks: https://learn-elixir.dev/

Live Coaching + Recorded Content + Major Projects

Whether your goal is to deploy a personal project or take your programming career to the next level, Learn Elixir can help!

Welcome to learn elixir week six, module two. In this video, we're going to talk about how we can create air systems in our application to make it easier for us to debug and solve issues as they come up. They're two main ways that we handle failure inside of elixir. The first is by using exceptions. And the second is by using status couples, exceptions are fatal and are only acceptable when status couples, aren't a feasible option. Say for example, your connection to the database crashes, and you can no longer run any function. You're probably going to want an exception saying that your connection has crashed versus a status type of return. If you were doing some sort of retry on the database, or you had a function that called the database, and if it aired, you had another path for it. This is where you'd probably want a status topple. Instead, exceptions are really only used when we want to crash the application or process because the exception is fatal. And often we don't recover from exceptions. Even though there are keywords to rescue and catch exceptions, they're very rarely used inside of elixir and even in hurling's and elixirs code base, they are used very seldomly exceptions basically mean we have no backup path. And in programming we try and have backup pass for almost everything. So this doesn't typically happen all too much. One of the things that we can do to make our exceptions a bit easier is to actually separate our exceptions out and make custom exceptions. There is a list of exceptions that already exist, that we can search for by searching for exceptions and the documentation to make it easier for us. We like to separate out our errors versus the ones that are built in. And so to do that, we built our customers. This is also very useful for monitoring services because when you're in a monitoring service like app signal, it actually counts exceptions based off of the error type. So if you're to return a runtime error for every single layer that you see, you'll get 10,000 instances of runtime errors and you may not get all the debugging and photos since it'll typically only show the first 10 to 15 actual exceptions. And so you'll get the first 15 runtime areas and what types of areas you're getting within that. But anything else beyond that is going to be lost. So if you use a custom exception, it'll make it easier because the air monitoring service can aggregate on that exception type itself. There are a few different options. Exceptions have that make it easier to debug for us. The first is by giving it a message. The second is by adding some stack info by using process.info, current stock trace. This can also be done by calling exception dot format stack trace, which actually formats that Sam chase into a string instead of being a top of the list, the last piece of debugging info that you'll want to give people is whatever relevant metadata is available for that specific call. For example, if you're searching for a user and you hit at some unrecoverable error, maybe you want to return nine user ID as well as some relevant metadata, because perhaps it's that users look up that is causing the crash. These are just some of the ways that we can add some more info to custom exceptions and how we create custom often looks like the following. So inside of our module, we actually define another module. And this is probably one of the only cases where it's acceptable to actually define modules within modules, because we don't want to define a bunch of individualized modules for all of our hair cases. This could get quite messy. So in this case, we define our module and then we define our exception module, which is called invalid parameters air inside this, we define that the exception has two keywords for AMS and message. And so our parameters are the keyword that we can pass in. And so you can see, we did that by passing in the inspect for hymns. So it's actually going to be a string. And we also have our message, which is just going to be whatever the message we want to actually raise this error. We use the raise keyword in elixir, along with the hair and then its parameters. So in this case, we raised the, my module dot invalid parameters there. And we pass in a message of not valid with some parameters that will get logged up as well with the same error we can actually rescue if we ever needed by using the try rescue combo. So we can wrap our call inside of a try. And if it does raise, we can rescue it by matching on that air type. This is pretty useful because we can match on a different exception types that we get. However, this is still generally frowned upon and you'll want to reach for a status Topal.