.NET Return value vs thrown Exception Design question

Question

Let\'s assume we have a method handling operations in a tree hierarchical data structure located in a class handling such a structure.

Let\'s look closer at one of t

Answer 1

Rather than ask whether something should return a value or throw an exception, one should ask what a function is promising to do. If a function promises to move a node, it should throw an exception if it can't. If a function promises to move a node if possible, or indicate via return value that it can't be moved, but only throw an exception if the data structure is fundamentally corrupt in some way beyond that implied by the ability to move the node, it should do that. Sometimes it can be useful to provide functions of both the "do it" and "try it" varieties.

As for what type of exception to throw, I frankly dislike the concept of throwing most built-in exception types from user code, since there's no nice programmatic way to tell whether an ArgumentException was thrown from your routine, or from some routine that was called by your routine, and most exceptions say nothing about the quality of the underlying data structure.

If one is trying to e.g. parse a file from disk and integrate it with an existing data structure and an exception is thrown, it doesn't matter whether the exception was an ArgumentException, or a SubscriptOutOfBoundsException, or a DiskReadErrorException, or whatever. The most important thing is whether the parse attempt was rolled back in such a fashion as to leave the data structure valid; of secondary importance is whether it might be possible to parse the file another way or under other circumstances. The type of exception really only matters to the extent that it can answer those first two questions.