For my game, I am considering to use exceptions in development builds to recover from some scripting errors, so that the development environment for the game is not disrupted. But I also want to make sure these exceptions take absolutely minimum costs in release builds. So a simple exception implementation of aborting the program may be useful.
I understand that this can also be implemented as some macros, but --exceptions:abort can guarantee that absolutely minimum costs would be spent on exceptions throughout the whole program.
I am not sure how others are using exceptions in Nim, but --exceptions:abort would be useful as long as all exceptions raised are actual errors close to be irrecoverable.
I missed somehow the post about quirky exceptions when you made it, but enjoyed reading it now.
I've done something similar in C and C++ objects for the past 20 years or so, and it works great; I call it "failure mode":
For example, let's say we are implementing a streaming serializer to some format (e.g. IFF - this was especially useful there). Once an error is detected (e.g. disk full), we set a "failed" flag on the object. Every "write" call to the serializer checks that "failed" flag, and does nothing if it is set.
This significantly simplifies the code structure - instead of having to check a return-value/errno after every write (C) or consider all the possible execution paths through our code (C++), you can just write it assuming everything works, and check the failure mode status in the end.
(For optimization, you can check it in the middle; however, if failures are rare, the code simplicity and obvious execution path are much more important).
I had not thought about this until I read about quirky exceptions, but there might be room for a macro to implement "failure mode" - e.g. mark procedures related to an objects, such that if the "failed state" flag is up, they just return immediately -- though, all my thoughts so far are "nah, it should just be written explicitly like in the old C days".
I was referring to that article for performance implications of C++ exceptions in the context of game development:
There is a lot of debate as to whether this is acceptable for PC games, but when it comes to consoles the issue becomes much more black and white.
The original article has more details, which I don't quote them in full here. In summary, whether exceptions are acceptable for game development is debatable, but I think most people in the same context tend to not pay the cost upfront.
I think the term "determinism" at the end of article is not exactly in the same sense as you're talking about. As I understand it, the author basically says that games should never run into any exceptional situations, and thus exceptions are usually not needed for games.
The original article has more details, which I don't quote them in full here.
No problem, I did read it completely. The article is terrible but going through all the points where I don't agree with it isn't too productive.
But even if the "details" in that article were true for C++ (and they are not), it's all hardly relevant for Nim. For example, you don't need to rewrite exception based code just because you move the code over to consoles which have a bad toolchain setup for C++ exceptions. (Do they though? Consoles these days either use clang or msvc based compilers...) It simply doesn't apply, Nim is not C++, the compiler can map Nim exceptions to mechanisms that are not easily available in C++.
And btw I don't like exceptions at all, it's just that I dislike silly arguments about exceptions even moreso.
It's a bit sorry to hear that. I made sure the article is representative of what people think in the game industry before posting the link, or at least people with similar mindset to me.
C++ exceptions are relevant because it's the best Nim can do in the traditional sense of exception handling (i.e. not quirky or abort), assuming the C++ compiler uses an efficient exception handling implementation. I referred to someone else's article to avoid debating whether C++ exceptions are acceptable for games, but you should see it's a controversial subject.
You're right that Nim's exceptions are open to be implemented or interpreted differently by the compiler, and that's why I asked about --exceptions:abort here, so that I can make use of exceptions for the development builds where they are more useful, while still being able to avoid the potential risk of writing sub-optimal programs.
I am aware that the article is outdated about game consoles, but it's still true that the C++ compiler is out of control from game developers, and can't be relied on for efficient exception handling implementations.