Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completion of error handling #2

Open
elfring opened this issue Apr 2, 2018 · 15 comments
Open

Completion of error handling #2

elfring opened this issue Apr 2, 2018 · 15 comments

Comments

@elfring
Copy link

elfring commented Apr 2, 2018

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

@glouw
Copy link
Owner

glouw commented Apr 2, 2018

I'll take a handle for xtload() for fopen. Not too concerned with calloc or fopen for writes failing.

@elfring
Copy link
Author

elfring commented Apr 2, 2018

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

@glouw
Copy link
Owner

glouw commented Apr 2, 2018

A little overkill in my opinion

@elfring
Copy link
Author

elfring commented Apr 2, 2018

I prefer a more complete error detection and exception handling.

@glouw
Copy link
Owner

glouw commented Apr 2, 2018

Okay, I'll pop in ecalloc() and efopen() wrappers

@glouw
Copy link
Owner

glouw commented Apr 2, 2018

assertations for callocs and fopens were added instead

@glouw
Copy link
Owner

glouw commented Apr 2, 2018

actually, now that I think about it, asserts can be disabled globally. efopen and ecalloc were added instead.

@elfring
Copy link
Author

elfring commented Apr 3, 2018

Thanks for your small source code improvement.
There are still more function calls to reconsider.

@glouw
Copy link
Owner

glouw commented Apr 3, 2018

scanf you mean? I'll patch it

@elfring
Copy link
Author

elfring commented Apr 3, 2018

Functions like fclose() and fprintf() will need also further software development attention, won't they?

@glouw
Copy link
Owner

glouw commented Apr 3, 2018

No, assuming that efopen() was successful, fclose() and fprintf() can be used without worry.

@elfring
Copy link
Author

elfring commented Apr 4, 2018

Your assumptions are questionable in this case. There are additional failure possibilities to consider.

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

@glouw
Copy link
Owner

glouw commented Apr 4, 2018

I rely on runtime analysis with valgrind. Static analysis is typically overkill at times. The metrics supplied by gcc's -Wall and -Wextra is usually enough.

@elfring
Copy link
Author

elfring commented Apr 4, 2018

Would you like to extend the development methodology with any software tools?

@glouw
Copy link
Owner

glouw commented Apr 5, 2018

Developments done for the most part as this is a practice in minimalism, If you're looking for a fully developed neural net library then checkout FANN (https://github.com/libfann/fann).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants