Writing Code That Holds Up: Reliable Programming Practices

UPI Study › Courses › Software Engineering › Free lessons › Lesson 12.2 Free with a free account

Writing Code That Holds Up: Reliable Programming Practices

Software Engineering · Chapter 12: Reliability Engineering and SecuritySection 12.2 · lesson 76 of 1036 min · free with a free account

← Reliability Engineering: Definitions, Goals, and Getting StartedNext lesson: Measuring How Well Systems Perform Over Time →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Behaving sensibly when a file is missing, a call times out, or input is unexpected.

  • Explain what makes code reliable, beyond the happy path
  • Describe defensive programming, and where it matters most
  • Distinguish failing safely from quietly hiding a problem
  • Apply coding habits that make failures easy to notice and diagnose

Transcript

Everything said in the video, section by section (776 words). Read along, or search it.

Reliability Engineering and Security

Writing Code That Holds Up: Reliable Programming Practices

Code that works when everything goes right is easy. Code that still behaves sensibly when a file is missing, a network call times out, or a user types something unexpected, is a harder standard. That standard is what this section is about.

Correct vs. Reliable

When Things Don't Go to Plan

Code that produces the right answer when everything goes according to plan is correct. But it is not necessarily reliable. Reliable code keeps behaving sensibly when the things around it do not go according to plan. A missing file. A malformed input. A network call that never returns. Two closely related practices build that reliability into code as it is written. Defensive programming assumes that things will go wrong. And error handling decides what to do, once they actually do.

Table 1

Defensive Programming Techniques

Defensive programming means writing code that does not simply trust its inputs, its callers, or its environment. Instead, the code checks its assumptions explicitly. Input validation checks that incoming data is the right type, shape, and range, before it is used. Preconditions state explicitly what must be true for a function to behave correctly, and check it. Boundary checking confirms values fall within valid limits, like array indices. And fail-fast means stopping immediately and visibly when an assumption is violated, rather than continuing on bad data.

Figure 1

Check at the Trust Boundary

Defensive programming matters most at a trust boundary. That is any point where data arrives from outside the code's direct control, such as user input, a network call, or a file on disk. Code on the far side of the boundary can reasonably assume the data has already been checked. Code sitting at the boundary itself cannot assume anything of the kind. That is where the checks belong.

Figure 2

No Handling vs. Specific Handling

Defensive checks catch a problem. Error handling decides what happens next. Here is the same function, written two ways. It reads a file, and turns its contents into a number. The risky version has no error handling at all. The moment the file is missing, or its contents are not a number, it crashes with a raw, unhelpful exception. Whoever called it has no clean way to respond. The defensive version catches each specific failure, and raises a clear, purpose-built error that says exactly what went wrong. And notice what it does not do. It never silently swallows the error and returns a default value, as if nothing happened.

Think About It

A Crash vs. a Silent Default

Think about this. Why is silently returning a default value, such as zero, usually worse than crashing loudly? A crash is visible immediately, right where the problem occurred. A silently substituted default lets bad data flow quietly through the rest of the system. It then causes a confusing failure somewhere else entirely, far from its actual cause.

4 Habits

Reliable Coding Habits

A handful of habits, applied consistently, cover most of what separates reliable code from code that merely works most of the time. Fail fast. Stop as soon as an assumption is violated, rather than running on data already known to be bad. Never fail silently. A caught error should be handled, logged, or re-raised with context. It should never simply be discarded. Catch specific errors, not everything. Catching a broad error type risks hiding failures the code was never prepared to handle. And validate at every trust boundary, even if the data was already validated somewhere upstream.

Apply It

A Default Age of 18

Let's apply that. A function reads a user-submitted age field. It catches any exception that occurs, and returns a default age of eighteen, without logging anything. What are two problems with this approach? First, catching any exception is too broad. It risks hiding failures the code was never prepared to handle. Second, silently returning a default without logging hides the failure entirely. A bad age can flow through the rest of the system, instead of surfacing where it occurred.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Defensive programming is writing code that explicitly checks its assumptions about inputs, callers, and the environment, rather than trusting them. A trust boundary is any point where data enters code from outside its direct control. That is where defensive checks matter most. Fail-fast is stopping immediately and visibly when an assumption is violated. And error handling is deciding how code responds once a failure is detected, by handling it, logging it, or re-raising it with context.

Key Takeaways

What to Carry Forward

To pull this together. Reliable code keeps behaving sensibly when something goes wrong, not just when everything goes according to plan. Defensive programming checks assumptions explicitly, and it matters most at trust boundaries. Good error handling catches specific failures and responds to them clearly. It never hides a failure behind a silent default. And four habits cover most of it in practice. Fail fast, never fail silently, catch specific errors, and validate at every trust boundary.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Writing Code That Holds Up: Reliable Programming Practices

What is defensive programming?
Defensive programming means writing code that explicitly checks its assumptions about inputs, callers, and the environment instead of trusting them. Common techniques include input validation of type, shape, and range, stating and checking preconditions, boundary checking such as validating array indices, and failing fast by stopping immediately and visibly when an assumption is violated. The goal is code that behaves sensibly when things go wrong, not just on the happy path.
What is a trust boundary in programming?
A trust boundary is any point where data enters code from outside its direct control, such as user input, a network call, or a file on disk. Defensive checks matter most there, because code at the boundary cannot assume the data has been checked. A good habit is to validate at every trust boundary, even if the same data was already validated somewhere upstream.
Why is returning a silent default value worse than crashing?
A crash is visible immediately, right where the problem occurred, while a silently substituted default lets bad data flow quietly through the rest of the system. That bad data then causes a confusing failure somewhere else, far from its real cause. For example, catching any exception on an age field and returning 18 without logging hides the failure, so a caught error should be handled, logged, or re-raised with context.
Why should code catch specific exceptions instead of all exceptions?
Catching a broad error type risks hiding failures the code was never prepared to handle, while catching specific errors lets each known failure get a clear, deliberate response. A function that reads a file and parses a number should handle a missing file and invalid contents separately, raising purpose-built errors that say exactly what went wrong. Code that catches everything tends to mask unexpected bugs instead of surfacing them.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →