Comments (6)
Good & useful observation.
This has actually been bothering me for some time. With me having some more time to spend on Anvil right now, I'll try to get this addressed for the coming update.
from anvil.
Sorry but I have to disagree with using abort() and hears the why:
- Anvil is a library to be used by other applciations? A 3rd party lib should never ever abort a process. At the very least provide a way to override the call to abort(). Just because something bad happend in Anvil code I might have a clean/controlled way to perform an app shutdown.
- abort() is fine on unixs/gdb/xcode but for MSVC abort() is a bad idea as the process is going down as the debugger kicks in. To this end you should use assert/_wassert or __debugbreak which pauses the process so other threads don't die or resources released.
from anvil.
@madwax - I have to respectfully disagree with your first point:
abort()
is a perfectly reasonable thing to do in a 3rd party library as well. An assert is for errors that cannot be recovered from. This means that allowing the program to continue running is potentially undefined behavior, and that is potentially a security hazard.
If allowed to continue running, the program may do many terrible things, such as hanging in an infinite loop or overflowing the stack. That could allow for code injection attacks or privilege escalation. Allowing user code to intercept the call to abort()
just means now the user has a callback where they can't be sure what the state of the system is like when they get it. How far did your library code get before the bug happened? Is there some file your library was working on that's only half-written?
If you do have some cleanup routine that's so important that it needs to be run no-matter-what, you are already screwed anyway because the library you're using has a bug in it and may be about to do something like "dereference a null pointer" or "write to a read-only memory location" that's going to abort the program anyway. So you already have to have some other way of dealing with that.
To your second point - I don't have MSVC right in front of me, but I'm pretty sure abort()
in a debug build does give the debugger an interception point. If I'm wrong then I guess I agree that it's better to use the built-in MSVC assert()
function.
My main reason for not straight-up suggesting it instead of abort()
is that a lot of people want custom assert messages or to do a little something more (like logging the failure) instead of just aborting with the default error message. I guess you could accomplish the same thing by writing your own assert function and ending it with ::assert(false);
from anvil.
@marti4d - I (and a number of colleagues) will just have to disagree with you in that case.
- I have a big problem with using asserts from a deign point of view. A 3rd party library should check it's inputs first and prevent an unrecoverable condition from happening in the first place, that's why we have exceptions in C++ or error codes.
- I don't also agree with you definition of assert means. Assert() is there to aid development allowing inputs/conditions/outputs to be tested. This is why they should be compiled out in release builds however people don't.
- While I agree most people don't handle terminal situations properly but that's on them. I know that the app I'm thinking about using Anvil in does have safe dirty shutdown code path that does stuff like flushing log files.
- If your app is a Win32 when you call abort() it just disappears. Having been faced with very large and complex applications that have been released all of a sudden "disappearing" without any information in a log file (or message) is a support nightmare. I have been down that road to meany times.
I offer regarding point 1) : https://www.softwariness.com/articles/assertions-in-cpp/
from anvil.
@madwax - I could also point you to several articles that state the opposite - Including "The C++ Programming Language" by Bjarne Stroustrup, "Code Complete" by Steve McConnell, and "C++ coding standards: 101 rules, guidelines, and best practices" by Herb Sutter and Andrei Alexandrescu.
Here is a link that includes cited sources to all those books and the respective section it's discussed.
For the record though, let me be clear about what I'm saying about asserts. I'm not saying you should be using assert()
instead of doing proper checking of inputs/outputs and reporting errors via return codes or exceptions. Not at all. If it's something you can handle, report, and recover from, then do it.
What I'm saying is that asserts are for logic errors - Bugs in your program that represent conditions that should never be true by-design, or else you've hit some undefined state that your testing didn't catch, and that you can't design your program to handle.
Example - Your class has some member variable it uses to index into an array. Class invariant states that the index should always be valid. But through some program bug (maybe you forgot to decrement it in a weird corner case), it now points off the end of the array.
What should you do if you detect that error in a later function call? There's nothing you or the user can reasonably do to recover from it. The library is literally in a state it never thought it should be in.
I hear you about to say, "Well then throw an exception! This is C++ after all!" Not so fast. Your class is in an invalid state. If you throw, its destructor will get called, and so will the destructors of other classes that may rely on it. Who knows what the destructors will do given the library is in some state it never expected to exist. The dtor may use that invalid index in some for-loop to try and free stuff, at which point it will run off the end of the array.
This is why all those authors are saying that the best thing you can do is throw your hands up in the air and go, "I should just stop running - Anything I do may potentially make the situation worse."
from anvil.
@marti4d - I know the theory and don't disagree with it however my opion is based on passed experiances of others and myself (been at this for +20 years, now I feel old!) working on some very large projects. sorry as for using exceptions (I personlly don't like them tbh) that's why we have them, to inform us of out of bounds conditions plus I think it's bad-design not to make safe an object that throws an exception if it is to be reused.
In the end this comes down into one of those holy war issues we all say we hate but secretly love ;) but I'm shutting up now.
from anvil.
Related Issues (20)
- Why can't the user recreate swapchains?
- Suggestion: Add CMake option to use SDK location for glslang library HOT 2
- BaseDevice::is_extension_enabled does not work with instance extensions?
- VK_ERROR_EXTENSION_NOT_PRESENT error if device group extension is not supported by GPU HOT 2
- Not building on ubuntu 18.10 HOT 3
- Unhandled VK_ERROR_OUT_OF_DATE_KHR when Anvil-based program with window is minimized with Nvidia drivers HOT 3
- Queue::submit with blocking-flag set does not guarantee command buffer completion? HOT 1
- Assertion failure when using specialization constants HOT 1
- Assertion failure in BaseDevice::init with a Radeon R9 Fury HOT 1
- GCC 8+ does not compile successfully. (-Werror=class-memaccess) HOT 5
- Crash when submitting queue on Nvidia GPUs HOT 2
- Why is HLSL support turned off if ANVIL_LINK_WITH_GLSLANG flag is set? HOT 1
- record_bind_pipeline(..., PipelineID) is a O(logn) function, n count of pipelines. A faster alternative might should be added.
- QueryPool::get_query_pool_results calculates query size incorrectly
- Concerning wstring-to-string conversion in WIN32 implementation HOT 1
- Unusable with NVidia HOT 1
- get_image_format_properties uses stencil usage flags of 0, which is not allowed
- Error compiling with GCC 9 on Linux HOT 1
- Error Compiling with VS CMake HOT 2
- Is there any future roadmap? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from anvil.