Module 2 – Start an application and handle failure paths
Design a small and honest lifecycle test
Keep one successful sequence and separate experiments for an empty id, an empty name, a request before start, and a second start. Record the SDK messages exactly, but explain the cause in your own words. After a normal stop, a new start is possible in this sandbox because stop resets the state; verify that behavior rather than inferring it from a name.
A useful review distinguishes application policy from SDK behavior. Your program may stop after an error; that is your decision. The SDK may return an error; that is the contract observed here. Explain both, and keep production-runtime questions in a clearly labeled follow-up list instead of inventing missing behavior.
Complete this lesson
Answer every check correctly to earn your lesson certificate. Feedback helps you review and try again.
Sign in · Save your progress and earn a certificate for this lesson.