Completion of error handling
elfring opened this issue · 16 comments
Would you like to add more error handling for return values from functions like the following?
This is a good idea, we should have error handling there. The rest of the engine sources use functions from Engine/Base/Memory.h with error handling, but ECC does not link to anything else so it needs separate error handling.
I suggest to avoid ignorance of return values a bit more.
Are you interested to apply aspect-oriented software development?
How do you think about to encapsulate error detection and corresponding exception handling as a reusable aspect in your software?
How exactly do you imagine that?
How do you think about to improve static source code analysis also for your software?
Do you find information sources like the following useful?
- Article "A Reusable Aspect for Memory Allocation Checking"
- Document "Aspect-Oriented Software Development - An Introduction" by Johan Brichau and Theo D'Hondt
- Paper "On Typesafe Aspect Implementations in C++" by Daniel Lohmann and Olaf Spinczyk
The last link doesn't work for me, and the first two don't really answer my question. Memory allocation functions are already error-checked in the engine, see Engine/Base/Memory.h. What exactly do you propose to change in there and what benefit will it bring?
Memory allocation functions are already error-checked in the engine, …
Are there any functions left over where null pointers will not be handled by the mentioned memory allocation approach?
How do you think about to delegate the source code transformation for more complete exception handling to a development tool like "AspectC++"?
Would you like to reduce efforts for source file maintenance in any ways?
Please answer my previous question first.
What exactly do you propose to change in there and what benefit will it bring?
- I propose to handle cross-cutting concerns in a more structured way.
- You can benefit from the specification of special source code patterns by automatic code generation, can't you?
I don't know. You make no clear indication of what you propose. But feel free to try coding that into Serious Engine and we'll see if it really brings any benefit.
Would you like to look a bit more at possibilities around the combination of pointcuts and advices into reusable aspect specifications?
No thanks, if that wouldn't be too hard I'd like to see how exactly your proposition will affect Serious Engine code. In other words, can you show me some code diffs?
Do you get further ideas from the following example for a small AspectC++ script?
…
aspect string_duplication_check
{
advice execution("% * strdup(...)"): after()
{
if (*tjp->result() == NULL)
abort();
}
};
…
It seems more complicated than already existing AllocateMemory function that does just that error check. I don't understand why you think it is better.
- Does the function "strdup" get the needed memory from the mentioned customised allocation approach?
- Is the aspect specification easily extensible for more use cases?
I'm sorry, but this conversation doesn't seem to be constructive. You initially made a good point, but then didn't propose a concrete and useful code modification. As I said, you are free to try whatever you wish, maybe you were right after all. If you manage to implement aspect-oriented approach in Serious-Engine, that's great, I'd love to see that in action. But until then I'll have to close this discussion.
Would you like to care for the failure possibility of a function like "fprintf"?