{"id":297,"date":"2015-06-03T12:36:27","date_gmt":"2015-06-03T10:36:27","guid":{"rendered":"http:\/\/blog.thecodecampus.de\/?p=297"},"modified":"2025-04-22T10:50:42","modified_gmt":"2025-04-22T08:50:42","slug":"client-side-errors-in-rich-internet-application-architectures","status":"publish","type":"post","link":"https:\/\/www.thecodecampus.de\/blog\/client-side-errors-in-rich-internet-application-architectures\/","title":{"rendered":"Client-side Errors in Rich Internet Application-Architectures"},"content":{"rendered":"

Problem<\/h1>\n

When building applications with frameworks like AngularJS, we usually create so called “Rich Internet Applications” (RIA). The architecture of a RIA differs from a “traditional” application in several aspects:<\/p>\n

    \n
  1. The server is (almost) stateless<\/li>\n
  2. The client is stateful<\/li>\n
  3. Server and client communicate over a coarse-grained interface<\/li>\n
  4. The client contains (more) business logic<\/li>\n<\/ol>\n

    With good reason, AngularJS get’s hyped quite a lot and the blogosphere is full with articles explain how to implement a RIA architecture with AngularJS. AngularJS is particularly good at implementing e.g. the client state and business logic. Take for example the whole dependency injection mechanism and the support for test-driven development in the API.<\/p>\n

    However, one important aspect often gets overlooked, simply because we, the developers, are not used it: Dealing with errors on the client side<\/strong>. Why are we not used to it? In old\/traditional architectures the UI state<\/em> and business logic<\/em> is is implemented on the server. Every (non-trivial) click, state transition, interaction etc. is handled on the server meaning unexpected errors, bugs, etc. are always caught and end up in our Logback\/SLF4J\/whatever log file. Often the default behavior is already enough (Servlet engine catches the error, Log library handles the error) and we rarely design this part of our application explicitly.<\/p>\n

    Back to AngularJS. As stated above, writing applications in AngularJS means writing business logic and UI state in the client. What if your code contains an error? What if one of your dependencies contain an error? Well, we will never know (unless you call your users and ask them check the browser’s JavaScript console, of course).<\/p>\n

    \n\"Angular\n<\/picture>\n<\/a><\/p>\n

    Solution<\/h1>\n

    Closing this gap involves three tasks:<\/p>\n

      \n
    1. Catching all errors on the client side<\/li>\n
    2. Sending them to the server<\/li>\n
    3. Logging them<\/li>\n<\/ol>\n

      This blog article will concentrate on the first item. Implementing item two and three should be obvious. However, for the second item, instead of sending error messages to your server, you could use services like:<\/p>\n