Marking DNM because I've not tested this yet, just posting for discussion.

tox does pass on my laptop, at least.

I discussed this with @cobrien . He pointed out that koji-smokey-dingo has an additional feature, a complaint attribute. https://github.com/obriencj/koji-smoky-dingo/blob/master/kojismokydingo/init.py

Currently each raise statement determines its own message string.

The purpose of complaint is that there is essentially always the same initial prefix to each message.

It means NoSuchBuild("foo-bar-baz") can be raised and caught at the very top of the client execution and turn into a No such build: foo-bar-baz with a single exception block (for example).

I've just noticed that "BEGIN kojikamid" logic is broken now. It needs to be wrapped in exceptions.py and added to vm/fix_kojikamid.sh. Basically kojikamid is a standalone script and needs everything needed implanted to it.

Ah, thanks, I did not know what that "BEGIN" logic was. I would like to learn the history of that sometime.

From https://github.com/ktdreyer/koji-ansible/issues/188, I think we should add DuplicateNameError and DuplicatePriorityError classes too.

@ktdreyer do you want to continue to work on this one or should I create that fix_kojikamid part?

The kojikamid issue can be addressed by:

• adding koji/exceptions.py to the list of files to check in fix_kojikamid.sh
• propagating the # BEGIN/END kojikamid dup # lines

That said, I am concerned about the sudden inflation of highly specific exceptions here. We'd need to add a new exception every time we add a new datatype. For that matter, it doesn't look like we have a NoSuchX exception for all our existing data (e.g. host, external repo, btype, buildroot).

I think clearly the fault-to-exception situation is not where it needs to be, but I think it might need more than just more exceptions.

Updated in #3348