Game Development Reference
In-Depth Information
External Data Is Evil
Typically, exceptions in an application are thrown because of invalid or nonexis-
tent data. External data can be provided from a database, keyboard input, files, a
registry, or a network socket. You can never trust external data because there is no
way to be certain that the external data exists or is valid. You may also end up with
insufficient privileges to access the external data.
Aside from reading data, most external data sources have write capability, in which
case there is also some sort of repository for the data as well. You may end up with
insufficient privileges or not enough memory, or the device can suffer from a phys-
ical fault as well. It is important to recognize that the best thing to do is build solid
code that handles external data errors in a stable and informative manner.
The safest approach when dealing with external data is to validate the data before
doing anything else with it.
Creating Custom Exceptions
There is a common misconception among developers regarding the use of
System.Exception and System.ApplicationException . These exception types are used
throughout the .NET Class Framework and form the base of many derived types,
but you should never throw them explicitly. The truth is, these types are much too
broad and generic to be thrown; you should instead be creating and throwing cus-
tom exceptions if a suitable exception type does not yet exist.
Another fallacy is that custom exceptions should be derived from
System.ApplicationException . This used to be the correct approach but has now
been identified by Microsoft as incorrect. You should instead be deriving all cus-
tom exceptions from System.Exception . One of the main reasons for this change is
an assortment of issues when using third-party libraries in your code. You may
have a function that calls a third-party method, which in turn throws a
System.ApplicationException , and you may also throw that same exception later on
in your code. When the exception leaves the method and arrives at the exception
handler, who threw it? The best approach is to create exception class hierarchies
that are as wide and shallow as possible, the same approach typically used with the
structuring of class hierarchies.
All custom exceptions should also support the three default constructors to pro-
mote consistency between your custom exceptions and the built-in framework
exceptions.
Search Nedrilad ::




Custom Search