Tag Info

New answers tagged

-1

Right-biased Either. It can't be ignored, it must be handled, it's completely transparent. And IF you use the correct left handed error type it conveys all the same information as a java exception. Downside? Code with proper error handling looks disgusting (true of all mechanisms).


3

... I wonder if once the program is deployed in production, isn't it also valid to simply log a warning and proceed the execution? Short answer: No. Every function you write runs in its only tiny little world that only knows about the argument values passed to it. It can only change or reinterpret the intention of those values if it understands the ...


2

In your examples you are not talking about failing early but rather about how to handle expected failure cases. Handling expected failure cases You gave the similar questions module as example. It can be aware, that one of its submodules may not be able to deliver and then just shows the rest of the questions that it got by its submodules. A counterexample ...


4

As usual, there are obvious upsides and downsides to coercing. It will let your program run on in production, when it is weak and alone and has no one to hold its hand; it must manage whatever conditions it is put into all by itself, and warping to the minimum value is the obvious thing to do. If crashing or skipping a task altogether would be very expensive ...


7

If logging is critical to your application, then one should stop the application if logging fails. If not critical, then being somewhat defensive one could have a secondary component to handle logging failures that logs/alerts to a secondary source. But even that is not fool proof and you will have to consider what happens if the secondary logger fails ...


12

When you encounter exceptions within the logger itself, you shouldn't use the logger to log its own exceptions. The reason for that is that: You may be stuck in an infinite loop. Imagine that within your logger, you have a conditional branch which wasn't tested (and generates an exception). Imagine that once the condition is met, any further reported ...


3

Generally, what is the preferred method for the problem described above, or which method is preferred in which cases? The prefered method looks like this: class Object { ... }; std::istream& operator>>(std::istream& in, Object& obj) { /* classic "in" operator*/ } Client code (1): Object o; if(std::cin >> o) { // do ...


3

Don't confuse "exception" with "rare" The main point of exceptions and exception handling is keeping different types of code apart: The code that provides the main functionality (the "happy path" code) Everything else: The code that handles all those 973 other cases where not everything has worked out wonderfully and precisely to your main ...



Top 50 recent answers are included