Book Image

Learning ServiceNow - Second Edition

By : Tim Woodruff
5 (1)
Book Image

Learning ServiceNow - Second Edition

5 (1)
By: Tim Woodruff

Overview of this book

This book is an updated version of Learning ServiceNow, that will cover the new and updated features of the ServiceNow platform. It will show you how to put important ServiceNow features to work in the real world, while introducing key concepts via examples of managing and automating IT services. It'll help you build a solid foundation of knowledge, and will demonstrate how to effectively implement and configure modules within ServiceNow. We'll show you how to configure and administer your instance, and then move on to building strong user interfaces and creating powerful workflows. We also cover other key elements of ServiceNow, such as notifications, security, reporting, and custom development. You will learn how to improve and automate your business' workflow and processes. By the end of this book, you will be able to successfully configure and manage ServiceNow like a pro.
Table of Contents (19 chapters)
Learning ServiceNow Second Edition
Contributors
Preface
Index

Server-side debugging


Server-side debugging can consist of debugging server-side scripts and other behavior, as well as performance and security issues. Debugging server-side scripts can often be slightly more difficult, as the exact source of the undesired behavior is not necessarily logged or thrown as an error message visible on the client. Instead, you must search through the logs for thrown errors, and sometimes use trial-and-error and custom log messages to determine the exact source of the issue. For this reason, using try/catch() blocks in your server-side code can be a good idea. This is also true of client-side code in fact, but it is especially important with server-side code.

Note

While try/catch() blocks are a great way to build in error-handling behavior, it should not be relied upon to control the flow of your code. They should only be used when the catch block can handle the error in some sensible way. Otherwise, pass the error up the call stack and perhaps a higher-level function...