molovo/crash

Proper error handling, exceptions and try/catch for ZSH

Crash

Proper error handling, exceptions and try/catch for ZSH.

Installation

zulu

zulu install crash

Manual

git clone https://github.com/molovo/crash crash
cp crash/crash /usr/local/share/zsh/site-functions # Or anywhere else in $fpath

Usage

Set up the global error handler

Crash comes with a global error handler, which prints a readable error and stack trace both for user-created exceptions and traditional shell exit codes.

autoload -Uz crash && crash register

throw TestException 'This is a test' # Will cause the error handler to be displayed

Try/catch

Crash comes with the functions try, catch and throw, allowing you to handle exceptions much as you would in a 'proper' programming language.

autoload -Uz crash && crash register

# The function we're going to call
function do_something() {
  echo 'Start to do something...'
  throw RainbowException 'Unicorns!'
  echo 'This message will never be displayed'
}

# A function to handle any caught exceptions
function error_handler() {
  local exception="$1" message="${(@)@:2}"

  echo $exception # RainbowException
  echo $message   # Unicorns!
}

try do_something
catch RainbowException error_handler

License

Copyright (c) 2016 James Dinsdale [email protected] (molovo.co)

Crash is licensed under The MIT License (MIT)

Team

• James Dinsdale

crash's Issues

All crash related commands and features crash when used on latest version of Oh My ZSH

Hello, I am using Oh My ZSH and whenever I throw an error or do a try command, ZSH immediately crashes. Not sure how to fix this.

Crash Version: Latest (just cloned)
Terminal: iTerm2
Oh-My-ZSH Version: Latest

Allow try/catch statements to be nested

This may or may not be possible. The try command needs to launch a subprocess to allow the exception to be caught, which means that modifying the global environment is not possible. To allow statements to be nested we'd need to maintain an 'exception stack' in an array, but cannot do this in its current form due to the use of a subprocess. Thrown exceptions are currently reported back to the global process by echoing the exception and message, so we could maintain the stack outside of the try block, but my first attempt at this didn't work. Something to look into.

Add unload command

The error handler fires on the occurrence of any non-zero exit code, but there are many instances where we want a program to exit gracefully without the stack trace being printed to the screen. Will add an unload command which will remove the error handler, so that it can be called prior to exciting.