You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most methods executed by step runners can raise a exceptions. Until now this was handled within those methods, but it has proven itself to be quite cumbersome. It's quite easy to forget to properly wrap a method invocation with a try-catch and thus allowing for an issue in a single step to fail a whole blueprint. Also - that's quite a boilerplate-heavy solution.
As a potential solution - exceptions would be handled in the orchestrating BlueprintRunner.php, thus "globally" protecting the execution flow, with no need for extra boilerplate and no risk of exception-leakage.
The text was updated successfully, but these errors were encountered:
### What does this PR do?
- removes the try / catch block from the `RmStepRunner`
- renames some variables in the test class for better readability and to
match linting standards
### What problem does it fix?
- the runner was catching IOExceptions, but we agreed it shouldn't #65
- some variables could've been named better
### How to test if it works?
- this PR includes tests for `RmStepRunner`
- all tests should pass for all supported PHP versions
`MkdirStepRunner` will now:
- handle both relative and absolute paths
- throw an exception if the directory it wants to create already exists
- throw an original Symfony Filesystem `IOException` not rewrapping it
into a `BlueprintException`, as agreed in #65
### What problem does it fix?
- until now the runner would only handle absolute paths
- has thrown an exception in a bad way
- we use this step in the `examples` directory, and since it only
accepted absolute paths and we have provided it a relative path the
example was flawed
### How to test if it works?
- this PR includes a full suite of tests for this runner
Most methods executed by step runners can raise a exceptions. Until now this was handled within those methods, but it has proven itself to be quite cumbersome. It's quite easy to forget to properly wrap a method invocation with a try-catch and thus allowing for an issue in a single step to fail a whole blueprint. Also - that's quite a boilerplate-heavy solution.
As a potential solution - exceptions would be handled in the orchestrating
BlueprintRunner.php
, thus "globally" protecting the execution flow, with no need for extra boilerplate and no risk of exception-leakage.The text was updated successfully, but these errors were encountered: