Tags: error

29

sparkline

Tuesday, April 2nd, 2019

Idiosyncrancies of the HTML parser - The HTML Parser Book

This might just be the most nerdily specific book I’ve read and enjoyed. Even if you’re not planning to build a web browser any time soon, it’s kind of fascinating to see how HTML is parsed—and how much of an achievement the HTML spec is, for specifying consistent error-handling, if nothing else.

The last few chapters are still in progress, but you can read the whole thing online or buy an ePub version.

Tuesday, August 7th, 2018

Console methods

Whenever I create a fetch event inside a service worker, my code roughly follows the same pattern. There’s a then clause which gets executed if the fetch is successful, and a catch clause in case anything goes wrong:

fetch( request)
.then( fetchResponse => {
    // Yay! It worked.
})
.catch( fetchError => {
    // Boo! It failed.
});

In my book—Going Offline—I’m at pains to point out that those arguments being passed into each clause are yours to name. In this example I’ve called them fetchResponse and fetchError but you can call them anything you want.

I always do something with the fetchResponse inside the then clause—either I want to return the response or put it in a cache.

But I rarely do anything with fetchError. Because of that, I’ve sometimes made the mistake of leaving it out completely:

fetch( request)
.then( fetchResponse => {
    // Yay! It worked.
})
.catch( () => {
    // Boo! It failed.
});

Don’t do that. I think there’s some talk of making the error argument optional, but for now, some browsers will get upset if it’s not there.

So always include that argument, whether you call it fetchError or anything else. And seeing as it’s an error, this might be a legitimate case for outputing it to the browser’s console, even in production code.

And yes, you can output to the console from a service worker. Even though a service worker can’t access anything relating to the document object, you can still make use of window.console, known to its friends as console for short.

My muscle memory when it comes to sending something to the console is to use console.log:

fetch( request)
.then( fetchResponse => {
    return fetchResponse;
})
.catch( fetchError => {
    console.log(fetchError);
});

But in this case, the console.error method is more appropriate:

fetch( request)
.then( fetchResponse => {
    return fetchResponse;
})
.catch( fetchError => {
    console.error(fetchError);
});

Now when there’s a connectivity problem, anyone with a console window open will see the error displayed bold and red.

If that seems a bit strident to you, there’s always console.warn which will still make the output stand out, but without being quite so alarmist:

fetch( request)
.then( fetchResponse => {
    return fetchResponse;
})
.catch( fetchError => {
    console.warn(fetchError);
});

That said, in this case, console.error feels like the right choice. After all, it is technically an error.

Thursday, July 5th, 2018

The trimCache function in Going Offline

Paul Yabsley wrote to let me know about an error in Going Offline. It’s rather embarrassing because it’s code that I’m using in the service worker for adactio.com but for some reason I messed it up in the book.

It’s the trimCache function in Chapter 7: Tidying Up. That’s the reusable piece of code that recursively reduces the number of items in a specified cache (cacheName) to a specified amount (maxItems). On page 95 and 96 I describe the process of creating the function which, in the book, ends up like this:

 function trimCache(cacheName, maxItems) {
   cacheName.open( cache => {
     cache.keys()
     .then( items => {
       if (items.length > maxItems) {
         cache.delete(items[0])
         .then(
           trimCache(cacheName, maxItems)
         ); // end delete then
       } // end if
     }); // end keys then
   }); // end open
 } // end function

See the problem? It’s right there at the start when I try to open the cache like this:

cacheName.open( cache => {

That won’t work. The open method only works on the caches object—I should be passing the name of the cache into the caches.open method. So the code should look like this:

caches.open( cacheName )
.then( cache => {

Everything else remains the same. The corrected trimCache function is here:

function trimCache(cacheName, maxItems) {
  caches.open(cacheName)
  .then( cache => {
    cache.keys()
    .then(items => {
      if (items.length > maxItems) {
        cache.delete(items[0])
        .then(
          trimCache(cacheName, maxItems)
        ); // end delete then
      } // end if
    }); // end keys then
  }); // end open then
} // end function

Sorry about that! I must’ve had some kind of brainfart when I was writing (and describing) that one line of code.

You may want to deface your copy of Going Offline by taking a pen to that code example. Normally I consider the practice of writing in books to be barbarism, but in this case …go for it.

Wednesday, March 7th, 2018

Frequently Asked Questions [CSS Working Group Wiki]

Rebuttals to the most oft-asked requests for browsers to change the way they handle CSS.

Monday, November 20th, 2017

Happier HTML5 Form Validation - daverupert.com

Dave uses just a smidgen of JavaScript to whip HTML5’s native form validation into shape.

Instead of being prescriptive about error messaging, we use what the browser natively gives us.

Wednesday, November 16th, 2016

Usability Testing of Inline Form Validation: 40% Don’t Have It, 20% Get It Wrong - Articles - Baymard Institute

I saw Christian speak on this topic at Smashing Conference in Barcelona. Here, he takes a long hard look at some of the little things that sites get wrong when doing validating forms on the fly. It’s all good sensible stuff, although it sounds a bit medical when he takes about “Premature Inline Validation.”

Tuesday, November 1st, 2016

What’s wrong with big data? | New Humanist

The view that more information uncritically produces better decisions is visibly at odds with our contemporary situation.

A superb piece of research and writing by James, skewering the technological determinism that underlies the current faith in “big data.” At best, this misplaced trust is inaccurate; at worst, it is deadly.

To the algorithmic imagination, the practice of journalism and the practice of terrorism appear to be functionally identical.

Wednesday, March 9th, 2016

Styling Broken Images

This is really, really clever. You can’t use generated content (:before and :after) on replaced content. The img element is replaced content …but only when the image actually loads. So if the image fails to load, you can apply specific fallback styles (using :before and :after).

Sunday, January 3rd, 2016

Simple inline error message pattern

This is my go-to method for adding validation messages to forms—I think I first heard about it from Derek—so it’s nice to see it corroborated by Steve:

Add the error message as a child of the label element associated with an input.

Thursday, November 13th, 2014

You’re So Smart You Turned JavaScript into XHTML

Web developers overwhelmingly rejected the draconian error-handing of XML …and yet today, web developers are embracing that very same error-handling model by rendering everything with JavaScript.

I don’t think it’s the way of the web to have your site fail and show a blank screen because some third-party dependency doesn’t load, JavaScript is turned off or because your developer left a trailing comma in a JavaScript object and didn’t test in Internet Explorer.

Friday, August 16th, 2013

The Killing Machines by Mark Bowden in The Atlantic

How to think about drones—an in-depth and fairly balanced article by Mark Bowden on drone strikes and the politics behind them.

In the long run, careful adherence to the law matters more than eliminating another bad actor. Greater prudence and transparency are not just morally and legally essential, they are in our long-term interest, because the strikes themselves feed the anti-drone narrative, and inspire the kind of random, small-scale terror attacks that are bin Laden’s despicable legacy.

Sunday, June 24th, 2012

mattdiamond/fuckitjs

This is possibly the most horrifying piece of JavaScript ever written. The license is good too.

Friday, June 6th, 2008

Bruce Schneier: Are photographers really a threat? | Technology | The Guardian

An excellent article that explodes the ludicrous myth that terrorists like to go around taking pictures of potential targets so therefore photographers are dangerous.

Sunday, April 20th, 2008

BBC NEWS | Magazine | Innocent photographer or terrorist?

The police in the UK seem to have problems distinguishing between "tourists" and "terrorists". East mistake to make, I guess.

Saturday, April 5th, 2008

HTTP errors - a photoset on Flickr

Friendlier HTTP errors.

400 Bad Request

Friday, March 21st, 2008

sneeu.com // Fuck.

I know it's childish but I think this may be my favourite 404 page ever.

Monday, October 29th, 2007

"Terrorist Buster" Logo — Central Intelligence Agency

No, this is not a joke. This really is the DCI Counterterrorist Center "Terrorist Buster" logo. Un. Be. Lievable.

Thursday, June 14th, 2007

do i look like a terrorist? on Flickr - Photo Sharing!

Brighton's Lomokev narrowly avoids a 30 day jail stretch without trial... a fellow commuter thought his beard looked suspicious and reported him to the police.

do i look like a terrorist?

Friday, February 23rd, 2007

Wednesday, October 18th, 2006

Battersea Power Station and Grosvenor Bridge on Flickr - Photo Sharing!

Dave Gorman tells of being stopped under the Prevention of Terrorism Act while taking pictures of Battersea Power Station. It's all very civilised. One of the coppers uses Flickr herself.

Battersea Power Station and Grosvenor Bridge