Make our error types more clear and useful

[Naved Ansari]

This stems from the discussion here

Errors we raise in our APIs should be distinct and clear enough so that we know how to process those errors just by looking at the type of it.

[Ian Denhardt]

Would be good to accumulate a list of cases that need dealing with. The one you mentioned:

• project_detach_node raises BlockedError if any resource is still attached to the node, but this includes NetworkingActions, where the appropriate behavior is to just wait, whereas with other resources the right behavior is to detach them.

Which also brings up the issue: in the latter case, the client might want to know what needs to be detached.

I can think of two general approaches off the top of my head:

• Make more error types, and use different ones for different things. It might make sense to e.g. split BlockedError into AttachedResourceError and PendingActionError, which would solve the specific case you brought up.
• Add more data to the error types. Running with the example above, AttachedResourceError could have some extra fields designating the type and identity of the attached resource.

It probably makes sense to combine these.

[Naved Ansari]

It might make sense to e.g. split

@jeremyfreudberg suggested that we inherit from BlockedError. That way we could either catch the specific child exception, or the parent one if we don't care about the exact type.

[Ian Denhardt]

It's not obvious to me that it makes sense to have these two use cases have a shared ancestor. Can you think of a case where we'd want to handle BlockedError but not care about the difference above?

Also, worth noting that the class hierarchy doesn't get sent across the wire.

[Naved Ansari]

Can you think of a case where we'd want to handle BlockedError but not care about the difference above?

Can't think of it now. Maybe in future, but in that case we might as well not do it.

Also, worth noting that the class hierarchy doesn't get sent across the wire.

Not sure what you mean by that? This code seems to work.

class ParentError(Exception):
    """Some Parent Error"""


class ChildError1(ParentError):
    """ChildError1"""


class ChildError2(ParentError):
    """different one"""


def raise_error1():
    raise ChildError1('Child1')


def raise_error2():
    raise ChildError2('Child2')

try:
    raise_error1()
except ParentError:
    # this will be printed
    print "Exception handled"

[Ian Denhardt]

Right, but the server sends them to the client as JSON, where the type is just a string, and it doesn't include information about what the superclasses are.

[Naved Ansari]

Ah, that's what you meant. Let's simply split the errors like you said.

[Ian Denhardt]

Works for me.

[Robin Kaul]

I am going to work on this so I wanted to know if there have been any other changes or if there are any suggestions apart from the ones above.

[Ian Denhardt]

Nothing jumps to mind; I think the proposed solution still makes sense.

The two suggestions should probably be separate prs, just to keep them small and self contained.