As a long time Delphi and C# programmer one become used to some features of the language and may not go deep into “philosophical” thinking about such features. This often happen with Asserts…
What is Assert or Assertion?
By its definition Assert:
- state categorically
- affirm: to declare or affirm solemnly and formally as true
- insist: assert to be true
- In Computing (wiki): “an assert is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place”
In general, using assert in the code proven to be useful in many situations because it “checks for a condition and outputs the call stack if the condition is false” and it could help to debug some strange situations in the code.
This method is for programmers to use. But what happen often when something is convenient, it started to be used excessively. Why it is happening?
Let’s look at the declaration of Assert in C# (3.x). There are two versions of the Assert(): Debug.Assert() and Trace.Assert(), both in System.Diagnostics namespace.
// Checks for a condition and outputs the call stack
// if the condition is false
[ConditionalAttribute("TRACE")]
public static void Assert(bool condition)
[ConditionalAttribute("TRACE")]
public static void Assert(bool condition, string message)
[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition)
[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition, string message)
As we can see from above code, Assert is to be used for Testing and Debugging and therefore should not be used as a way to present any information to the end-user.
Helping yourself
As useful as it seems, even then Assert infrastructure may not be used to full extend. In the sample declarations above we can see that logic can be invoked with and without providing any additional information.
Imagine how useful is a message “Project raised an Assert in line X” compare to “Project raised an Assert with the Message in line X”.
First option gives you idea where something failed, where second actually tells you what went wrongand where. Let’s use power of the tool-set and provide ourselves with useful information.
Assert is NOT for an end-user
I was asked recently (this seems to be a ongoing discussion) – “Why a programmer should not be using asserts as a regular approach in code conditions validation even when it comes to a production code?”
By default, Assert would show a message box with some information and the current Call Stack. This information, while being helpful to the developer, would not tell much to the user.
With custom TraceListener introduced, message can be hidden from the user and information could be stored, but it is not how it should be used by definition.
If information is expected to be presented to the user in any form, it could be achieved in a form not an exceptional, intended for debugging, situation, but by using regular methods: message box, application log, Windows event log, etc.
Even in the case of component development it is desired to use exceptions (raise/throw) to “bubble” proper message to the error handling layer.
The throw statement is used to signal the occurrence of an anomalous situation (exception) during the program execution.
Assert is a conditional logic
Last, final and probably major concern here is that in Release environment Debug and even Trace functionality would be disabled and therefore, any code/logic which depend on Assert() would be suppressed and all the nice validations became worthless (see declaration above)… and Access Violation errors starting pop up unexpectedly.
