njmason22/lab_server
1
0
Fork 0
generated from mwc/lab_server
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

notes.md

Browse Source
This commit is contained in:
njmason22
2026-02-22 01:58:07 -05:00
parent 9731c66ab0
commit 7d28076b26
1 changed files with 30 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
notes.md
View File

@@ -41,11 +41,40 @@
(unless you have fancy tools), but you can infer some of the calls based on the
program's behavior. Describe a few routes which you think may exist for your
chosen program's backend server.
# https://www.weather.gov/
# https://forecast.weather.gov/MapClick.php?lat=41.6523491&lon=-74.6956932 is a GET call.
# https://forecast.weather.gov/showsigwx.php?warnzone=NYZ062&warncounty=NYC105&firewxzone=NYZ208&local_place1=Monticello%20NY&product1=Winter+Storm+Warning&lat=41.6523&lon=-74.6957 is a GET call.
# There aren't any POST calls on this server from a regular client's point-of-view.
# However, obviously, this server and website are being constantly updated by a whole team of programmers
# who have certain rights and access. So, from a regular client's point-of-view,
# the data is viewed in "read-only" mode.
4. In your own words, what is an exception? When might it be useful to handle an
exception? When is it better not to handle an exception, and instead let the
program crash?
# An exception is more than invalid data. An exception should "handle" a data-type mismatch,
# an out-of-range input or a null input that causes a divide-by-zero process,
# and situations where the Internet connection fails during a "submit" of data for processing.
# According to Google Search, there are many scenarios where an exception should not or cannot
# be handled:
# "A program should crash immediately when it encounters an unrecoverable error,
# corrupted state, or illegal operation that threatens data integrity or system stability.
# Rather than continuing with incorrect data, crashing allows for immediate
# error identification and prevents further, more severe damage.
# Key Scenarios for a Program Crash:
# Data Corruption: When internal data structures become invalid, it is safer to crash than to risk saving corrupt data.
# Failed Invariants: When assertions fail (e.g., code reaches a spot that 'should never be reached'), the program should terminate.
# Unrecoverable Resource Depletion: Running out of critical resources like memory or disk space.
# Unexpected System State: When an operation occurs that the program is not designed to handle,
# such as unexpected hardware failures or missing critical files.
# Illegal Operations: Actions disallowed by the operating system, such as invalid memory access (segmentation faults) or division by zero.
# 'Crash Early' Principle:
# This philosophy encourages developers to make software fail loudly as soon as an unexpected event occurs,
# rather than masking the error and continuing in a broken state. This makes debugging easier and prevents
# invalid data from being processed.
# When NOT to Crash:
# Programs should not crash on routine, expected errors, such as invalid user input
# (e.g., text in a numeric field) or minor networking issues, but should instead handle them gracefully." - Google Search