Cross-Domain Error Handling
Cross-Domain Error Handling
We all say that error handling's important, but be honest, none of us put the amount of thought into it that we should. Here, you can jumpstart your error handling efforts, save yourself some time, and get back to the things you really want to work on.
Join the DZone community and get the full member experience.Join For Free
Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required
And, the way you do this mapping matters. Let's look at Java into HTTP as an example.
Java actually has pretty decent error handling capabilities. As a community, Java developers have transitioned from using checked exceptions everywhere to using a combination of checked and runtime exceptions. This makes lots of sense—many error conditions are simply unrecoverable, so there's no need to treat them as a checked case. Plus, supporting too many exception types leads to really obtuse API definitions that obfuscate the API design with excessive error handling focus. Error handling's important, but it's not the focus of an API after all. Function is.
Now, when you use this pattern, you need to ensure that thrown runtime errors are caught and handled at some point high in the calling stack. This is vital and isn't checked by the compiler, so developers need to remember to implement this properly.
We still need a runtime error hierarchy, though.
Errors and HTTP
HTTP has a well thought out, extensively-used collection of error codes. In order to take advantage of them, you need to implement a meaningful collection of exception types that you can appropriately map into the correct HTTP codes. This is really important—not doing this makes things difficult for your users, difficult for you when you need to debug problems, can make you a target for hackers, and makes you look like an idiot.
Let's cover these in order, shall we?
Difficult for Users
So, are you delivering content directly to your users or via something like Angular? The code you return can make a big difference either way. Most people know what a 404 error is (I messed up my URL when I typed it in!) or a 500 (That website's broken!). They'll retry a 404, retyping a URL, but if you return a 500? Maybe not.
Difficult for You
Are you having to fix a problem reported by one of your users? Have you ever? If the answer is no, well, I know you don't program for a living. We all end up fixing user reported problems. Having a meaningful error code can really help you find bugs.
Target for Hackers
If someone's going to try to hack you, they're not going to do it through the sections of code that work. They're going to find flaws and try to exploit them. Did you return a 404? Well, hackers are users too, they'll check the URL they used. Did you return a 500? Well, that's a different story. 500 error codes are targets—the hacker's found an error condition you didn't handle, and they'll try to exploit it.
Look Like an Idiot
Seriously, HTTP has oodles of error codes. You're returning 500 for every error? Say if you catch a SQL injection attempt, you return a 500 instead of, say, a 400, which makes more sense? It just makes you look like you didn't bother Googling "HTTP error codes." That's an idiot move.
In order to handle errors correctly in modern applications, we need to pay attention to how errors are handled throughout the stack, from end-to-end. And, it makes us look better too.
Opinions expressed by DZone contributors are their own.