Cross-Domain Error Handling

DZone 's Guide to

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.

· Web Dev Zone ·
Free Resource

So, today, we regularly deal with error propagation across domains. From JavaScript into HTML, from Python into HTTP... well, from lots of languages into HTTP, honestly.

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.

error handling, http, java

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}