New answers tagged

0

I'll give you an example first (but at the very end is the answer why the controversy). Let's suposse you are editing a document in a Java-based document editor and after you are done you choose File->Save as... and you chose to save the document into a volume you don't have write permission on. The Editor wouldn't crash on you with an ugly stacktrace, it ...


0

However, it also seems that everyone does it and it seems to be good practice. Yes, everyone does it indeed, so it's a practice, but is it still good? Several people are questioning that: http://mnapoli.fr/approaching-coding-style-rationally/ (The Exception suffix § context: php) the linked video, https://vimeo.com/album/2661665/video/74316116 (skip to ...


2

"Exception Handling". Two little words but which is more important? I would argue, it's the latter. In a critical piece of code, should exceptions describing a situation which does not makes sense be handled? Counter-question: If a situation occurs which "does not make sense", what can you[r code] do about it? If the answer is "something useful"...


3

A major difference between C++ programs and Javascript scripts is that a C++ program typically runs for a much longer time than a Javascript script. A C++ program with a GUI executes continuously while you are working with the program. A Javascript script on the other hand only executes for a short time to respond to an event and then it ends (even if it ...


1

The JavaScript event handler is executed by the browser engine which also handles rendering of CSS/HTML, user interaction, network traffic and so on. When the engine executes an event handler, uncaught exceptions in the JavaScript code terminates the execution of the event handler code, but does not terminate the browser engine, since this would mean a ...


2

That's not true at all. The JS exception is not uncaught in the slightest. It's simply caught by the browser. A C++ UI library can trivially produce the same effect by calling the onClick handler inside a try/catch. The difference in behaviour has nothing to do with language - it's all library.


4

From your applications toplevel point of view, you do want to "crash". If a "nonsense" (your words) exception happens. In a controlled way: Either via an UnhandledExceptionFilter or toplevel catch(Exception). It's also the easiest option: You don't have to do anything here. Just let the exception propagate. From comment: The point is that the code ...


2

Many other good answers have been written, I just want to add a short point. The traditional answer, especially when the ISO C++ FAQ was written, mainly compares "C++ exception" vs. "C-style return code". A third option, "return some type of composite value, e.g. a struct or union, or nowadays, boost::variant or the (proposed) std::expected, isn't ...


2

Define "critical". If your software powers a pacemaker or Google.com, wrap the code to catch exceptions and log them in detail. And hope that somebody actually reads the logs and you promptly fix the problem. Otherwise, I prefer to just crash and throw an Exception. Quietly logging an unexpected fatal error is inferior since it will likely get ignored ...


1

First, as others have stated, things are not that clear cut in C++, IMHO mostly because the requirements and restraints are somewhat more varied in C++ than other languages, esp. C# and Java, that have "similar" exception issues. I'll expose on the std::stof example: passing an empty string to std::stof (will throw invalid_argument) not a programming ...


1

This is a highly subjective issue, as it is part of design. And because design is basically art, I prefer to discuss these things instead of debate (I'm not saying you are debating). For me, exceptional cases are of two kinds - those that deal with resources and those that deal with critical operations. What can be considered critical depends on the problem ...


2

From the Design by Contract perspective, define the preconditions and postconditions of the function, and any class invariants, which specify the contract between different parts of the system. This makes clear the responsibilities of the function and its caller. Define the action (which can be throwing an exception), to be taken on violation of the contract,...


8

The std::bitset string-based constructor only exists since C++11, so it should have been designed with idiomatic use of exceptions in mind. On the other hand I've had people tell me logic_error should basically not be used at all. You may not believe this, but, well, different C++ coders disagree. That's why the FAQ says one thing but the standard ...


12

First, I feel obliged to point out that std::exception and its children were designed a long time ago. There are a number of parts that would probably (almost certainly) be different if they were being designed today. Don't get me wrong: there are parts of the design that have worked out pretty well, and are pretty good examples of how to design an ...


0

A "finally" block contains that is executed, no matter what. Especially it is intended to be executed if an exception is thrown. If you put code into a finally block and then prevent it from being executed, for example by setting cleanupNeeded = false, then you are not using it as intended. The code above could be changed to acquireResource(); try { // ...


2

The simple solution here is to restructure your code. Rather than: acquireResource(); try { // stuff cleanupTidy(); } catch (Exception e) { cleanupFromException(e); throw e; } Move stuff to another method: acquireResource(); try { doStuff(); cleanupTidy(); } catch (Exception e) { cleanupFromException(e); throw e; } ...


1

I've found a (somewhat icky) solution with less boilerplate. I was passing in my exception so I could add any exceptions thrown while closing to the suppressed exceptions of the original exception. However, try-with-resources does this for me: acquireResource(); try (Closeable c = this::cleanup) { // stuff } This is not a good use of try-with-...


1

I want to implement the logic of a finally block, but only if no exceptions are thrown A block of code that's run if no Exceptions are thrown? That's just a block of code after everything else that might throw an Exception. However, this will not call cleanupTidy if the code in the try block does any jumps - return, continue, break, etc - to the ...


1

You are right to be concerned. Your code implies that there is something about an exception not having been thrown that makes you want to call cleanupTidy(). That is not true, but someone reading the code in future (even you reading the code in 20 years' time) may think that it is. The following code executes identically to yours, but does not tell lies: ...


2

I like to quote Bill Venners saying, "Throw exceptions at programmers, not at code." I think it's a good rule of thumb. Why not concatenate all information into the description string of the exception? The cost of String concatenation won't be incurred unless the exception is thrown. You aren't going to do anything with that info besides print it out ...


2

What's wrong with it? Exceptions are still objects, they are just passed in a different way when being thrown. Function Properties can make exceptions be more informative than just an exception message that (supposedly) is human-readable. If you catch the exception, you can receive information regarding the issue, and probably fix it automatically. ...


0

Programming is about work I think the easiest way to answer this is to understand the progress OOP has made over the years. Everything done in OOP (and most programming paradigms, for that matter) is modeled around needing work done. Every time a method is called, the caller is saying "I don't know how to do this work, but you do know how, so you do it ...


1

Suppressing warning for an entire method is suspect. Better to suppress the warnings for the specific line, with a comment. e.g. @SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast



Top 50 recent answers are included