search

opentoonz / opentoonz_docs

OpenToonz User Manual
http://opentoonz.readthedocs.io
28 stars 26 forks source link

Completion of error handling #181

Open elfring opened 8 years ago

elfring commented 8 years ago

Would you like to add more error handling for return values from functions like the following?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32274774-completion-of-error-handling?utm_campaign=plugin&utm_content=tracker%2F33713530&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F33713530&utm_medium=issues&utm_source=github).
RodneyBaker commented 3 years ago

After four years it seems the answer to this question might be 'no'. We'll have to take another look at this and error handling in general.

elfring commented 3 years ago

How do you think about to improve static source code analysis also for this software?

RodneyBaker commented 3 years ago

@elfring Good to hear from you. We'd have to look at the candidates and how it might fit into the current ecosystem. To this point most of the analysis has been at the individual level and the outlook for code analysis tools that costs anything is not good.

I must assume you have some suggestions and preferences.

elfring commented 3 years ago

There are also some free software analysis tools available.

I suggest to avoid ignorance of return values a bit more. Would you like to detect every error situation as early as possible?

RodneyBaker commented 3 years ago

Would you like to detect every error situation as early as possible?

We are several years behind the power curve so the term 'early' is a bit relative. Perhaps we can survey what is possible for new code that is being written as opposed to current and legacy code. In other words to chart a path forward into 2021 and beyond.

RodneyBaker commented 3 years ago

Concerning legacy code there is one (WIP) PR currently in the cue addressing basic cppcheck suggestions:

REF: https://github.com/opentoonz/opentoonz/pull/3647

RodneyBaker commented 2 years ago

Closing as I believe this has been addressed. @elfring please let us know if that is not the case.

elfring commented 2 years ago

I find the implementation of the class “TMutexImp” (for example) still questionable. :thinking: :crystal_ball: Is source code analysis evolving accordingly?

RodneyBaker commented 2 years ago

Thanks for the follow up. It's great to see you back in the Opentoonz arena again.

🔮 Is source code analysis evolving accordingly?

I'll guess no, although we have had some success in that in the not too distant past. It's hard to say if one of those efforts might have resolved this particular error handling concern. One PR in particular was set to blast through most of the ancient coding but it needed to be run after rather than just prior to release given the number of changes it was targeting. (Not ideal to troubleshoot right before a release). Sadly, the author of that PR didn't return to that task after the release.

Added REF: opentoonz/opentoonz#3647

Given we are half way to the release of v1.7, now would be a good time to solidify plans and get some of the most questionable code updated.

elfring commented 2 years ago

:thought_balloon: How do you think about to reopen this issue because of remaining development concerns?

RodneyBaker commented 2 years ago

I don't wish to take too much of your time but it would be educational to know more about your specific concerns.

Would you be willing to submit a PR to address and correct those specific concerns? (or to recommend someone willing to submit those changes)

elfring commented 2 years ago

… but it would be educational to know more about your specific concerns.

:thought_balloon: I recommend to take another look at linked information sources. The proper handling of cross-cutting concerns is a general development challenge.

(or to recommend someone willing to submit those changes)

Not yet.

I suggest to take corresponding development tools better into account. :thinking:

RodneyBaker commented 2 years ago

I should probably add...

New code submitted goes through the various tests (github actions and appveyor) and that takes care of the vast majority of code smells so in this way you could say Opentoonz code has definitely been evolving.

The older (and largely legacy) code still needs attention and that would appear to be the focus of our discussion here. Much of that code is still present because those areas of the program haven't been updated themselves with new/improved features and optimizations. This is perhaps the optimal road forward; to actually consider what the code is doing with respect to users and to update as appropriate.

To achieve this what we need even beyond code analysis is a clear path forward for the features of Opentoonz as a whole and the optimizations that go with user interactivity and workflow. As these paths get updated the automated tools in place then do their appropriate work.

elfring commented 2 years ago

… the automated tools in place then do their appropriate work.

:thought_balloon: Such tools (and available development resources) are also evolving according to various factors.

RodneyBaker commented 2 years ago

Reopening based on your continued interest @elfring which is much appreciated.

RodneyBaker commented 4 months ago

Transferring this to the Opentoonz documenation repo where discussion can continue regarding best practices for coding.