Error Handling

Reliable failure handling with prakritiTry, prakritiCatch, prakritiAtEnd, and prakritiThrow.

Theory

Error handling is the mechanism that keeps programs safe when unexpected conditions happen. Instead of crashing silently, PriyoScript lets you explicitly guard risky logic (prakritiTry), capture failures (prakritiCatch), run cleanup (prakritiAtEnd), and create your own failures (prakritiThrow). Good error handling improves reliability, user experience, and debugging speed.

Why this is critical

Programs are not judged by how they run in ideal cases, but by how safely they fail in real cases.

Error Handling API Table

Keyword	Syntax	Purpose
`prakritiTry`	`prakritiTry { ... }`	Wrap risky code
`prakritiCatch`	`prakritiCatch (err) { ... }`	Handle thrown/runtime errors
`prakritiAtEnd`	`prakritiAtEnd { ... }`	Always run cleanup block
`prakritiThrow`	`prakritiThrow "message"`	Create custom error

Error Object Quick View

Inside catch, err usually exposes:

Field	Meaning
`err.message`	Human-readable message
`err.code`	Error code (if available)
`err.stage`	Stage hint (syntax/compile/runtime) in advanced diagnostics

Example 1: Basic `try/catch/finally`

monalisa {
  prakritiTry {
    prakritiThrow "Something failed"
  } prakritiCatch (err) {
    priyoTell.Error("Caught: " + err.message)
  } prakritiAtEnd {
    priyoTell.Info("Cleanup done")
  }
}

Explanation:

prakritiThrow creates a failure inside try.
catch receives it in err and prints user-friendly message.
prakritiAtEnd runs regardless of success/failure.

Output:

Caught: Something failed
Cleanup done

Example 2: Validation before dangerous operation

monalisa {
  lisaaTask divide(a, b) {
    prakritiIf (b == 0) {
      prakritiThrow "Division by zero is not allowed"
    }
    priyoGiveBack a / b
  }

  prakritiTry {
    priyoTell(divide(10, 0))
  } prakritiCatch (err) {
    priyoTell.Warn(err.message)
  }
}

Explanation:

Business rule is enforced in function.
Caller handles error centrally instead of letting program crash.

Output:

Division by zero is not allowed

Example 3: Continue execution after handled error

monalisa {
  prakritiTry {
    prakritiThrow "Temporary network timeout"
  } prakritiCatch (err) {
    priyoTell.Warn("Recovering: " + err.message)
  }

  priyoTell("Program continues safely")
}

Explanation:

Error is handled locally.
Execution continues after catch block.

Output:

Recovering: Temporary network timeout
Program continues safely

Example 4: Inspect metadata (`message`, `code`)

monalisa {
  prakritiTry {
    prakritiThrow "Custom failure"
  } prakritiCatch (err) {
    priyoTell("Message: " + err.message)
    priyoTell("Code: " + err.code)
  }
}

Explanation:

Useful for logging and building user-facing diagnostics.
err.code may vary by error source.

Output:

Message: Custom failure
Code: (implementation-specific)

Example 5: Cleanup with `prakritiAtEnd`

monalisa {
  priyoKeep opened = "yes"

  prakritiTry {
    prakritiThrow "Operation interrupted"
  } prakritiCatch (err) {
    priyoTell.Error(err.message)
  } prakritiAtEnd {
    opened = "no"
    priyoTell.Info("Resource closed: " + opened)
  }
}

Explanation:

prakritiAtEnd is the right place for cleanup logic.
Cleanup runs even when error occurs.

Output:

Operation interrupted
Resource closed: no

Edge Cases

Case	Behavior
`catch` without `try`	Syntax/compile error
`throw` with non-string value	Still handled as throwable value
Error inside `catch`	New error propagates unless nested try/catch handles it
Error inside `prakritiAtEnd`	Can override earlier handled state and propagate
No `catch` present	Error bubbles to runtime/CLI printer

Debug tip

Keep try blocks small. Catch close to the risky operation so error context remains clear.

Comparison With Other Languages

JavaScript/Python/Java: same conceptual try-catch-finally model.
C: no native exceptions, usually return-code based error handling.
PriyoScript: similar model with humanized diagnostics and code-based explain flow.

Practice Questions

Concept Check

When should you use prakritiAtEnd instead of placing cleanup after catch? 2. Why is throwing a clear message better than generic text like "failed"? 3. What happens when an error is thrown but no catch handles it?

On this page