Practice: Writing Resilient Code with Error Handling

These exercises will help you practice the fundamentals of error handling in Julia, including try-catch blocks, the finally clause, and defining your own error types. By working through these examples, you'll gain confidence in anticipating and managing potential issues in your Julia programs.

Scenario 1: Handling Invalid User Input

A common source of errors is unexpected user input. Imagine a program that asks the user for their age. If the user types "thirty" instead of "30", our program might crash if we try to convert this text directly to a number. Let's see how try-catch can prevent this.

function get_user_age()
    println("Please enter your age: ")
    input_str = readline()
    age_value = -1 # Default invalid age

    try
        parsed_age = parse(Int, input_str)
        if parsed_age < 0
            # We can also throw an error for invalid (but parsable) input
            error("Age cannot be negative.") 
        elseif parsed_age > 150 # A simple upper bound check
             error("Age seems unusually high. Please re-enter.")
        end
        age_value = parsed_age
        println("Thank you. Your age is: ", age_value)
    catch e
        if isa(e, ArgumentError)
            println("Invalid input: '", input_str, "' is not a whole number. Please enter a numeric value for your age.")
        elseif isa(e, ErrorException) # Catches errors thrown by error()
            println("Validation error: ", e.msg)
        else
            println("An unexpected error occurred: ", sprint(showerror, e)) # More detailed error
        end
        println("Could not determine age due to an input issue.")
    end
    # You might return age_value or a status indicator in a real function
end

# Let's try calling it
get_user_age()

In this example:

• We use readline() to get input from the user as a string.
• The try block attempts to parse the input string into an Int. It also includes checks for plausible age ranges, throwing an ErrorException if a check fails.
• If parse fails (e.g., input is "hello"), it throws an ArgumentError. Our catch e block intercepts this.
• We use isa(e, ArgumentError) to check if the caught error e is specifically an ArgumentError. This allows us to provide a targeted message for parsing failures.
• If our custom error() calls are triggered (like for negative age), an ErrorException is thrown. We catch this with isa(e, ErrorException) and display its message via e.msg.
• The else part of the catch block is a fallback for any other unexpected errors, using sprint(showerror, e) to get a descriptive message.

Try running get_user_age() and entering various inputs like 25, abc, -5, or 200 to see how the different catch conditions respond.

Scenario 2: File Operations with finally

When working with external resources like files, it's important to ensure they are properly released (e.g., closed), even if errors occur during operations. The finally clause is perfect for this, guaranteeing execution of cleanup code.

function process_file_safely(filepath::String)
    io = nothing # Initialize 'io' outside try to ensure it's in scope for finally
    try
        println("Attempting to open file: ", filepath)
        io = open(filepath, "r") # Open for reading
        println("File '", filepath, "' opened successfully.")

        println("Processing file content...")
        line_number = 0
        for line in eachline(io)
            line_number += 1
            println("Read line ", line_number, ": ", line)
            # Simulate an error during processing for demonstration
            if line_number == 1 && rand() < 0.7 # 70% chance of error on first line
                error("Simulated error during file processing!")
            end
        end
        println("File processing complete.")

    catch e
        println("An error occurred while processing '", filepath, "':")
        println(sprint(showerror, e)) # Shows the specific error (e.g., SystemError, ErrorException)
    finally
        if io !== nothing && isopen(io) # Check if 'io' was successfully assigned and is open
            println("Closing file '", filepath, "'.")
            close(io)
        elseif io === nothing && !isfile(filepath)
            # This case means open() likely failed because the file doesn't exist.
            # 'io' would still be 'nothing'.
            println("File '", filepath, "' could not be opened (e.g., does not exist or no permissions).")
        else
            # This case could be if open() failed for other reasons, or if we got here without 'io' being an open stream.
            println("File '", filepath, "' was not open or already closed; no action needed in finally.")
        end
    end
end

# Create a dummy file for testing
open("mydata.txt", "w") do f
    write(f, "Hello Julia\n")
    write(f, "Error Handling Practice\n")
    write(f, "Ensure resources are managed\n")
end

println("--- Processing existing file (may trigger simulated error) ---")
process_file_safely("mydata.txt")
println("\n--- Attempting to process non-existent file ---")
process_file_safely("nonexistentfile.txt") 

# To see the simulated error more reliably, you might run the first call a few times.
# For example:
# for _ in 1:3 process_file_safely("mydata.txt"); println("---") end

# Cleanup dummy file
if isfile("mydata.txt")
    rm("mydata.txt")
end

Here's what's happening:

• We initialize io to nothing. This is important because if open() itself fails (e.g., file not found), io will not be assigned to a stream object. The finally block needs to handle this.
• The try block attempts to open and process the file. We've included a conditional error() call to simulate a failure during the file reading loop.
• The catch block handles any errors that occur within the try block, such as a SystemError if the file doesn't exist, or our simulated ErrorException.
• The finally block is important. It executes regardless of whether an error occurred or not.
• Inside finally, if io !== nothing && isopen(io) checks if the file was successfully opened and is still open before attempting to close(io). This prevents errors if open() failed or if the file was already closed for some reason.

This pattern ensures that resources like file handles are managed correctly. However, Julia offers a more idiomatic way for file handling that often simplifies this:

Using open with a do block

The do block syntax with open automatically handles closing the file, making the code cleaner and less error-prone.

function process_file_with_do(filepath::String)
    try
        # The 'do' block ensures 'io' is closed automatically
        open(filepath, "r") do io 
            println("File '", filepath, "' opened successfully (using do block).")
            println("Processing file content (do block)...")
            line_number = 0
            for line in eachline(io)
                line_number += 1
                println("Read line ", line_number, ": ", line)
                if line_number == 1 && rand() < 0.7 # Simulate error
                     error("Simulated error during file processing (do block)!")
                end
            end
            println("File processing complete (do block).")
        end # File 'io' is automatically closed here, even if an error occurs inside.
        println("File operation on '", filepath, "' finished successfully.")
    catch e
        # This catch block now handles errors from open() itself (e.g., file not found)
        # or any unhandled errors from within the 'do' block.
        println("An error occurred with '", filepath, "':")
        println(sprint(showerror, e))
    end
end

open("mydata_do.txt", "w") do f
    write(f, "Line one with do\n")
    write(f, "Line two with do\n")
end

println("\n--- Processing with 'do' block (may trigger simulated error) ---")
process_file_with_do("mydata_do.txt")
println("\n--- Attempting 'do' block on non-existent file ---")
process_file_with_do("another_nonexistent.txt")

if isfile("mydata_do.txt")
    rm("mydata_do.txt")
end

The do block syntax is generally preferred for file operations because it's more concise and Julia handles the resource cleanup automatically. The try-catch surrounding the open(...) do construct is then used to manage issues like the file not existing or unhandled errors from your processing logic within the do block.

Scenario 3: Custom Error for Application Logic

Sometimes, built-in error types aren't specific enough for your application's unique conditions. Julia allows you to define custom error types to represent these situations clearly.

Let's say we're writing a function to withdraw money from an account. We want to signal an InsufficientFundsError if the withdrawal amount exceeds the balance.

# Define a custom error type
struct InsufficientFundsError <: Exception
    balance::Float64
    amount_requested::Float64
    account_id::String
end

# Customize how our error message is displayed
function Base.showerror(io::IO, e::InsufficientFundsError)
    print(io, "InsufficientFundsError for account '", e.account_id, 
          "': Cannot withdraw \$", e.amount_requested, 
          ". Available balance is \$", e.balance, ".")
end

function withdraw_cash(account_id::String, balance::Float64, amount::Float64)
    if amount <= 0
        error("Withdrawal amount must be positive.") # Using a standard ErrorException
    end
    if amount > balance
        throw(InsufficientFundsError(balance, amount, account_id)) # Throw our custom error
    end
    new_balance = balance - amount
    println("Withdrawal of \$", amount, " from account '", account_id, "' successful. New balance: \$", new_balance)
    return new_balance
end

# Let's try it out
current_balance = 100.0
user_account = "ACC123"

println("--- Attempting valid withdrawal ---")
try
    current_balance = withdraw_cash(user_account, current_balance, 50.0)
catch e
    println(e) # Our custom showerror will be used if it's InsufficientFundsError
end

println("\n--- Attempting withdrawal exceeding balance ---")
try
    current_balance = withdraw_cash(user_account, current_balance, 200.0)
catch e
    if isa(e, InsufficientFundsError)
        # 'println(e)' automatically uses our custom 'Base.showerror'
        println("Custom Handling: ", e)
        # We can also access the fields directly for further logic if needed:
        # println("Account: ", e.account_id, ", Deficit: ", e.amount_requested - e.balance)
    else
        println("An unexpected error occurred: ", e)
    end
end

println("\n--- Attempting invalid withdrawal amount (zero) ---")
try
    current_balance = withdraw_cash(user_account, current_balance, 0.0)
catch e
    println(e) # This will be an ErrorException
end

Let's break this down:

1. struct InsufficientFundsError <: Exception: We define a new type InsufficientFundsError. It's a subtype of Exception, the base type for all exceptions in Julia. Our custom error stores balance, amount_requested, and account_id to provide context.
2. Base.showerror(io::IO, e::InsufficientFundsError): This is an optional but highly recommended step. By defining a method for Base.showerror specific to our InsufficientFundsError, we customize how instances of this error are displayed. This makes debugging and user feedback much clearer. When you println(e) or an error is caught and displayed by the REPL, this method is used.
3. throw(InsufficientFundsError(balance, amount, account_id)): Inside withdraw_cash, if the condition for insufficient funds is met, we create an instance of our custom error (populating its fields) and then throw it.
4. catch e with isa(e, InsufficientFundsError): When calling withdraw_cash, our try-catch block can specifically check if the caught error e is an InsufficientFundsError. This allows for more granular error management, treating this specific business logic failure differently from other potential errors (like network issues if balance came from a database).

Custom errors make your program's intent clearer and enable more sophisticated, application-specific error handling strategies.

Scenario 4: Graceful Degradation (Simulated)

Sometimes, parts of your program might depend on external services or operations that can fail (e.g., network requests). Instead of letting the entire program halt, you might want it to continue with reduced functionality or by using default/cached data. This approach is often called graceful degradation.

Imagine a function that tries to fetch a "message of the day" from a (simulated) network service. If the service is unavailable, we'll return a default message instead of crashing.

# Simulate a function that might fail (e.g., a network call)
function fetch_message_from_external_service()::String
    # Simulate a 70% chance of failure for demonstration
    if rand() < 0.7 
        error("Network service unavailable! Code: SVC503") 
    end
    return "Julia: High performance, dynamic, and fun!" # Successful fetch
end

function get_daily_message_with_fallback()
    default_message = "Keep calm and code in Julia. (Default message)"
    final_message = ""
    try
        message_from_service = fetch_message_from_external_service()
        println("Successfully fetched message from service: \"", message_from_service, "\"")
        final_message = message_from_service
    catch e
        # Check if it's the specific error we expect from the service
        if isa(e, ErrorException) && occursin("SVC503", e.msg)
             println("Warning: Could not fetch today's message (Service Error: ", e.msg, "). Using default.")
        else
            println("Warning: An unexpected issue occurred while fetching message (", sprint(showerror,e) ,"). Using default.")
        end
        final_message = default_message
    end
    return final_message
end

# Run a few times to see both outcomes (success and fallback)
println("--- Fetching Daily Messages ---")
for i in 1:5
    println("\nAttempt ", i, ":")
    displayed_msg = get_daily_message_with_fallback()
    println("Displaying: \"", displayed_msg, "\"")
end

In this example:

• fetch_message_from_external_service() simulates an operation that can fail by randomly throwing an ErrorException with a specific message pattern.
• get_daily_message_with_fallback() calls this service function within a try block.
• If fetch_message_from_external_service() succeeds, its message is used.
• If it fails, the catch block executes. Instead of re-throwing the error or crashing, it prints a warning message (and potentially logs the error e in a real application) and then returns a default_message. The program continues to function, albeit with potentially less current or complete information.

This approach makes your application more resilient to failures in its dependencies. The user experience is often better if the application can continue running with some default behavior rather than stopping entirely.

These scenarios cover common patterns for error handling in Julia. As you write more code, you'll develop an intuition for where errors might occur and how to best manage them. Remember that clear error messages, specific error types where appropriate, and judicious use of finally (or do blocks for resource management) contribute significantly to the reliability and maintainability of your software.

Further Practice Ideas:

1. Input Loop: Modify the get_user_age function to loop continuously until valid input (a non-negative integer within a reasonable range) is provided by the user.
2. Advanced Bank Account: Extend the withdraw_cash function. What if there's a daily withdrawal limit? Define and throw a WithdrawalLimitExceededError. How would you handle multiple accounts, perhaps reading balances from a dictionary?
3. File Data Aggregator: Write a script that attempts to read a file named numbers.txt. Each line of this file is expected to contain a number. Your script should sum all valid numbers.
   • If numbers.txt doesn't exist, print an informative message and exit gracefully.
   • If a line contains non-numeric text (e.g., "hello" instead of "123"), parse will fail. Catch this ArgumentError, print a warning indicating the problematic line number and its content, skip that line, and continue processing the rest of the file.
   • Ensure the file is always closed, even if errors occur.
   • After processing, print the total sum of valid numbers and a count of how many lines were skipped due to errors.