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
{{ message }}
Repository navigation
[test] check the error code when raising System Exit #128
Description
In tests/commands/test_bump_command.py#L86, we do not check the error code. It's possible to raise the same exception but not our expected case. Maybe we should refactor them as custom exceptions?
Maybe we can fix it in two steps. The first step is to check only the error code and merge it into 1.*. The second step is to refactor it into custom exceptions and release it in 2.0.
To be honest, I don't see much value in adding the checks for 1.x. The error code thing is an idea I had to give people flexibility to decide what to do on each error when writing configuration scripts, but I've never seen anyone do conditions on errors in bash, even less with commitizen.
So I say we don't waste time on it (be my guest if you want to do it, but I don't think it really adds value). And refactor into more expressive custom exceptions for 2.0
I think the error code is quite useful when I use some of the new features recently. I'm thinking of refactoring these errors into classes but still have the same error code which makes it a non-breaking change. @woile What do you think?
Activity
woile commentedon Jan 29, 2020
Yes, custom exceptions makes sense. But this would be a breaking change, we can schedule it for 2.0
Lee-W commentedon Jan 29, 2020
Maybe we can fix it in two steps. The first step is to check only the error code and merge it into
1.*. The second step is to refactor it into custom exceptions and release it in2.0.woile commentedon Jan 29, 2020
To be honest, I don't see much value in adding the checks for
1.x. The error code thing is an idea I had to give people flexibility to decide what to do on each error when writing configuration scripts, but I've never seen anyone do conditions on errors in bash, even less with commitizen.So I say we don't waste time on it (be my guest if you want to do it, but I don't think it really adds value). And refactor into more expressive custom exceptions for 2.0
Lee-W commentedon Jan 31, 2020
Yes, that makes sense. Do we have any plan on when or how we release 2.0? Maybe a branch
2.0so we can merge2.0-onlycommits into the branch?woile commentedon Jan 31, 2020
I've created a branch
next, we can start sending PR thereLee-W commentedon May 23, 2020
I think the error code is quite useful when I use some of the new features recently. I'm thinking of refactoring these errors into classes but still have the same error code which makes it a non-breaking change. @woile What do you think?
woile commentedon May 23, 2020
Great idea! Go for it!
woile commentedon Jun 26, 2020
@Lee-W can we close this ticket?
Lee-W commentedon Jun 26, 2020
Ah yes, I forgot it haha. Let's close it!