Standardize DFG Graph CRUD return types

[Affie]

Decide on and standardize behavior on return and exceptions for CRUD

[dehann]

FROM SLACK

Currently the behavior of GraphsDFG and CloudDFG is somewhat different.
We want it consistent, but i would not want the cloud breaking julia, but rather the ability to retry

[dehann]

I like the cloud graphs addVariable in that it does not error, but not the automatic update if it exists.
I would propose the behavior is to @error on exists and return false.

[dehann]

Update does not seem to change the graph structure in in-memory types which might be a bug?
It errors on GraphsDFG but creates with @warn on CloudDFG.
Create with @warn or @error seems logical

[dehann]

Delete might just return nothing with @error agian?

[dehann]

Hi Johan consistent definitely good, cloud @error with false a good start. The rerun false might be under question at some point since initially addVariable used to return the variable object. Maybe escalate the in memory to also be @error. Probably need a hard decision addVariable return type. Should limit to just one type I think.The retry can work well, although there is a discussion on whether user or driver has that responsibility. If it’s small then maybe a keyword argument to disable retry?Not sure on the return type for delete, that could perhaps be nice if the DFGVariable is returned, or empty if failed?

[dehann]

On retry i would say user responsibility, auto retry can maybe be implemented in RoME. What I meant was, rather return a false or nothing with an @error or @warn than throwing an exception that stops julia.

[dehann]

Agree not to throw exception. I’d suggest that that there is only one return type from the function for performance, but somehow indicates success or failure.

[dehann]

On addVariable!: IIF returns the variable, DFG true/false. What is preferred. I would think if the function name is the same it should have the same behavior.

[dehann]

definitely only one return type, but a Nothing Union eg. Union{Nothing, DFGVariable} might also be acceptable as the performance is not impacted that much since julia 0.7

[dehann]

Right, union types thing... theres something I’m not sure about yet. There is a macro type_warn which shows type instability which is slow. Do return Union in functions skip dynamic type inference — will be great if that’s the case. Sounds like 0.7 was able to do that..? At some point I’ll try the type_warn thing to see if Union return is stable, having a hard time understanding how that would be the case though. As long as things are type stable I think it would be good?