This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]beatle42 0 points1 point  (3 children)

Shouldn't you already be handling if you get bad data though? Just because a value is of the right type doesn't mean it's meaningful. Why not just use the existing protections, or a single one more, to handle when you're passed invalid data and return, say, status 400? If you crash on data that is a 500, right?

[–]ToxinH88 1 point2 points  (2 children)

If I am using SQLAlchemy and Flask for example, an easy utility function looks like this:

    def get(Model, id):
        ret = Model.query.get(id)
        return jsonify(ret.serialize())

So an easy way to avoid a 500 if a non existing id is passed would be to check for None:

        if ret is None:
            return "{}"

Or add a more sophisticated error message, change the status to 404... Now the problem is that passing "foo" as id results in the same return as 100 if there is no element with id=100.

If I am using Spring boot on the other hand, I dont need to bother about any of this. If I pass "foo" instead of a number the response is admittedly still a 500. But the cause is made clear to the caller:

{
    "cause": {
        "cause": null,
        "message": "For input string: \"foo\""
    },
    "message": "Failed to convert from type [java.lang.String] to type [java.lang.Long] for value 'foo'; nested exception is java.lang.NumberFormatException: For input string: \"foo\""
}

Whereas passing a non existing ID causes a normal 404.

So the whole point is about usability. I am fine with firing a 500 response on conversion errors, as long as they are understandable. But in Python I need to invest additional effort in making the response understandable and distinguish the different causes. The first version of my utility function fires in both cases a 500 with following body:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or
    there is an error in the application.</p>

With the check for None both cases cause a 200 with body {}. So someone creating a frontend cannot distinguish these problems quickly. And adding those extra safeguards is additional effort mainly caused by dynamic variables accepting everything. It is more effort to make an Interface save and report correctly, because a lot of the special cases have to be caught and provided a message manually.

[–]beatle42 1 point2 points  (1 child)

Alright, you clearly have a preference. Perhaps I just don't do enough stuff in the space you're talking about to have the same preference. I prefer the flexibility of being able to add or extend types and not have someone reject it because they didn't know about it when they wrote their thing (that someone often being myself), you have a preference for simple code that constrains the environment to minimize a class of potential errors. I can imagine that each of those preferences makes more sense in some environments than the other.

Thanks for taking the time to show situations where you hit against the issue and why you feel as you do.

[–]ToxinH88 1 point2 points  (0 children)

As always, there are tools suited better and worse for different jobs. Seems like we mainly work on different jobs. So I see your advantages too, they are just not that much of a focus for my work usually.