Tag Info

New answers tagged

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 ...


2

By adding some metadata to your object, either by inheriting from an abstract class that contains that data, writing a composite object, or something similar. In ASP.NET MVC 1, this would have been done by attaching a partial class to your entity (In the C# language, classes having the same name with the modifier partial in front of them are merely ...


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 ...


0

Synopsis: Exceptions are evidence of bad outcomes, bugs are (some of the) causes of bad outcomes. The problem (to be solved) isn't the exception, the problem is what caused the exception. Resoning: A bug is a defect in the design or implementation of a product (not limited to software). For example, not using a properly rated relay ...


1

You might legitimately raise an exception yourself, you would hopefully never introduce a bug on purpose.


0

All exceptions are not bugs. It can be a topic of debate that all bugs are exceptions or not. We can say exceptions are the events that are not part of the normal or expected flow of application. These events can be independent of how the code is written where as a bug is essentially result of bad code(like wrong calculation). Here is an example of how not ...


0

Since this question has been re-opened for a bounty, let me mention my CUJ article from 2003 entitled "An Exception or a Bug?", which seems to address exactly the OP's question. Basically, the article defines the terms "bug" and "exception" (giving examples), and proposes strategies for dealing with each. The article proposes not to "handle" bugs but ...


0

I have been pondering the same recently, and my tentative conclusion is that the mere question arises because the .NET Exception hierarchy is severely messed up. Take, for example, the lowly ArgumentNullException which might be a reasonable candidate for an exception you don't want to catch, because it tends to indicate a bug in the code rather than a ...


1

First off, having a catch block which only rethrows the exception is usually useless. But, the only real world scenario i can think of which makes sense to use throw ex instead of throw is if you're developing some sort of third party library which you by all means dont want anyone in the outter scope who's using your code to see the full stacktrace. Im not ...


5

You are both right. You don't want to lose the stack trace, but you may want to catch the lower level exception. Don't wrap the exception if it isn't adding information. I would call your ExceptionManager and TreatException a bit of a code smell - they are trying too hard to centralize exception handling. To re throw without losing the stack trace: ...


4

This is possible but has limitations. An implementation would utilize setjmp() / longjmp(). You can see an example implementation here: http://aceunit.sourceforge.net/doxygen/ExceptionHandling_8h.html Beware: return within try-blocks would be a bug!



Top 50 recent answers are included