Skip links

Sane defaults over Exceptions

January 4, 2017 7:21 AM - by Freek Lijten - 3 comments

Part of our work is defensive programming. A lot of webdevelopment is centered around taking input from a customer, processing it in some way and returning output. Since the source of input is out of our control we are used to writing all kinds of guards. Is this an integer (in case of a dynamically typed language), is it greater than zero, is it smaller than RANDOM_THRESHOLD, etc.

What I see a lot is people using exceptions or even intentional fatal errors for this. I think the reasoning is that since the application will always generate the correct values, the only thing to worry about is malicious attempts and we can show those people 404's or error pages without feeling remorse.

I didn't think much of this, but I've seen a major drawback lately while working on a site that is a bit bigger than I was used to. With over half a million visitors a week and lots of scrapers, bots and other stuff visiting, these exceptions and fatal errors clog up logging quite a bit. Not to the point that we can't handle the volume, but it generates false positives in monitoring channels and it is something we do not want to act upon anyway.

So while I'm happy to see some defensive programming I would be even happier if exceptional situations would be silently resolved to default situations, simply compare the first and the second example:

    // Great!
    if ($limit <= 0) {
        throw new SorryLimitTooLow();
    }
    if ($offset < 0) {
        throw new SorryOffsetTooLow();
    }

    // Better!
    if ($limit <= 0) {
        $limit = 10;
    }
    if ($offset < 0) {
        $offset = 0;
    }  

If the application makes an error we won't bother the user with it and we will notice during testing (Right?). If the user or a scraper tampers with urls or whatever, we won't bother ourselves with it in our monitoring channels. Everybody wins :)

Share this post!

Comments

  1. Patrick van BergenPatrick van Bergen Wrote on January 5, 2017 4:37:15 PM

    Blog \o/

  2. FreekFreek Wrote on January 12, 2017 4:04:17 PM

    It's been a busy few months, but I need to put stuff out there more again yeah :p

  3. Fabian SchmenglerFabian Schmengler Wrote on January 13, 2017 11:36:53 PM

    "if the application makes an error we won't bother the user with it and we will notice during testing (Right?)" - the reality is, we won't notice, or won't understand the error cause it's hidden. I'm not arguing against hiding recoverable errors from the user, but if they come from a bug in the application, I think they should be logged at least. Validating user input is a different topic and should be handled early.

Leave a comment!

Italic and bold

*This is italic*, and _so is this_.
**This is bold**, and __so is this__.

Links

This is a link to [Procurios](http://www.procurios.nl).

Lists

A bulleted list can be made with:
- Minus-signs,
+ Add-signs,
* Or an asterisk.

A numbered list can be made with:
1. List item number 1.
2. List item number 2.

Quote

The text below creates a quote:
> This is the first line.
> This is the second line.

Code

A text block with code can be created. Prefix a line with four spaces and a code-block will be made.