search

nfprojects / nfengine

Game engine
GNU General Public License v2.0
55 stars 4 forks source link

Exception handling #120

Closed lookeypl closed 6 years ago

lookeypl commented 9 years ago

Engine has multiple places, where error/exception handling and informing is just plainly terrible, if it exists at all. The project needs an exception system, which would handle all the errors both fast, and with all the needed informations.

Example locations, which need to be fixed (feel free to add your places):

The task is huge and requires some planning, so it needs discussion. Any approved ideas should appear on the list below:

mkulagowski commented 9 years ago

How about each place near LOG_ERROR? I'm almost sure that 1-3 lines after this log we can find return -1 or false or sth. Apart from that I think we should split that task - one part could be nfCommon, which on it's own is quite a piece of code.

lookeypl commented 9 years ago

Good idea @mkulagowski, added.

As for ideas, we should avoid try/catch blocks. These are slow and in realtime there might be some situations, which might cause an error, but the engine will be able to carry on after that (missing textures/models etc). Maybe regular errors should be handled by a code, but criticals should throw to leave from engine's loop?

Witek902 commented 9 years ago

I recommend reading this (everything): http://bitsquid.blogspot.com/2012/01/sensible-error-handling-part-1.html http://bitsquid.blogspot.com/2012/02/sensible-error-handling-part-2.html http://bitsquid.blogspot.com/2012/02/sensible-error-handling-part-3.html

lookeypl commented 9 years ago

Part 2 and 3 does not exist - could you update the links to correct ones?

Witek902 commented 9 years ago

Done

Witek902 commented 9 years ago

As a first step of this task I suggest replacing all return values form "enum class Result" to "bool" and removing the "Result" enum class in Core.hpp.

mkulagowski commented 8 years ago

This was discussed on the last meet. Functions that do not return anything, but their result may be important should return bool. All other forms of 'error' types should be abolished (meaning the likes of "Result" enum class from Core.hpp). LOG_ERRORs should be used as well, though there has been no problem with that.

Due to NOT designing any new exception system, this task is no longer huge - now it revolves around resolving issues in Window, which will probably be solved with #181 and finding eventual weird return types.