Note that there are some explanatory texts on larger screens.

plurals
  1. POError communication and recovery approaches in .NET
    primarykey
    data
    text
    <p>I am trying to do error communication and recovery in my C# code without using Exceptions. To give an example, suppose there is a Func A, which can be called by Func B or Func C or other functions. Func A has to be designed keeping reuse in mind. (This application has an evolving library where new features will keep getting added over a period of time)</p> <p>If Func A is not able to do what it is supposed to do, it returns an int, where any non-zero value indicates failure. I also want to communicate the reason for failure. The caller function can use this information in multiple ways:</p> <ol> <li>It can show the error message to the user, </li> <li>It may display its own error message more relevant to its context</li> <li>It may itself return an int value indicating failure to further ancestor caller functions.</li> <li>It may try to recover from the error, using some intelligent algorithm.</li> </ol> <p>Hypothetically, any function on which other functions depend, may need to communicate multiple things to its caller function to take appropriate action, including status code, error message, and other variables indicating the state of data. Returning everything as a delimited string may not allow the caller function to retrieve the information without parsing the string (which will lead to its own problems and is not recommended). </p> <p>The only other way is to return an object containing member variables for all required information. This may lead to too many 'state' objects, as each function will need to have its state object.</p> <p>I want to understand how this requirement can be designed in the most elegant way. Note that at the time of coding, Func A may not know whether the caller function will have the intelligence to recover from the error or not, so I do not want to throw exceptions. Also, I want to see whether such a design is possible (and elegant at the same time) without using exceptions.</p> <p>If the only way is to communicate using data objects for each function, then is it the way professional libraries are written. Can there be a generic data object? Note new functions may be added in future, which may have different state variables, or supporting information about their errors.</p> <p>Also note that since the function's return value is a 'state' object, the actual data what it is supposed to return may need to be passed as a ref or out parameter.</p> <p>Is there a design pattern for this?</p> <p>I have read the following articles before posting this question:</p> <p><a href="http://blogs.msdn.com/b/ricom/archive/2003/12/19/44697.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/b/ricom/archive/2003/12/19/44697.aspx</a></p> <p><a href="https://stackoverflow.com/questions/1308432/do-try-catch-blocks-hurt-performance-when-exceptions-are-not-thrown">Do try/catch blocks hurt performance when exceptions are not thrown?</a></p> <p><a href="https://stackoverflow.com/questions/1272342/error-handling-without-exceptions?rq=1">Error Handling without Exceptions</a></p> <p>I have read many other articles also, which suggest not to use exceptions for code flow control, and for errors which are recoverable. Also, throwing exceptions have their own cost. Moreover, if the caller function wants to recover from exception thrown by each of the called functions, it will have to surround each function call with a try catch block, as a generic try catch block will not allow to 'continue' from the next line of the error line.</p> <p><strong>EDIT:</strong></p> <p>A few specific questions: I need to write an application which will synchronize 2 different databases: one is a proprietory database, and the other is a SQL Server database. I want to encapsulate reusable functions in a separate layer.</p> <p>The functionality is like this: The proprietory application can have many databases. Some information from each of these databases needs to be pushed to a single common SQL Server database. The proprietory application's databases can be read only when the application's GUI is open and it can be read only through XML.</p> <p>The algorithm is like this:</p> <ol> <li>Read List of Open databases in Proprietory Application</li> <li>For each database, start Sync process.</li> <li>Check whether the user currently logged in, in this database has the Sync Permission. (Note: each database may be opened using a different user id).</li> <li>Read data from this database.</li> <li>Transfer data to SQL Server</li> <li>Proceed to next database.</li> </ol> <p>While developing this application, I will be writing several reusable functions, like ReadUserPermission, ReadListOfDatabases, etc.</p> <p>In this case, if ReadUserPermission finds that the permission does not exist, the caller should log this and proceed to next open database. If ReadListOfDatabases is not able to establish a connection with the Proprietory Application, the caller should automatically start the application, etc.</p> <p>So which error conditions should be communicated should exceptions and which using return codes?</p> <p>Note the reusable functions may be used in other projects, where the caller may have different error recovery requirements or capabilities, so that has to be kept in mind.</p> <p><strong>EDIT:</strong></p> <p>For all those advocating exceptions, I ask them: If Func A calls Func B,C,D,E,F,G and Func B throws an exception on some error condition, but Func A can recover from this error and will like to continue rest of execution i.e. call Func B,C,D,..., how does exception handling allow to do this 'elegantly'? The only solution will be to wrap calls to each of B,C,D,... within a try catch block, so that remaining statements get executed.</p> <p>Please also read these 2 comments:</p> <p><a href="https://stackoverflow.com/a/1279137/1113579">https://stackoverflow.com/a/1279137/1113579</a></p> <p><a href="https://stackoverflow.com/a/1272547/1113579">https://stackoverflow.com/a/1272547/1113579</a></p> <p><strong>Note</strong> I am not averse to using exceptions, if error recovery and remaining code execution can be achieved <em>elegantly</em> and without impacting performance. Also, slight performance impact is not a concern, but I prefer the design should be scalable and elegant.</p> <p><strong>EDIT:</strong></p> <p>Ok, Based on "Zdeslav Vojkovic" comments', I am now thinking about using exceptions.</p> <p>If I were to use exceptions, can you give some use case when not to use exception, but use return codes? <strong>Note:</strong> I am talking about return <em>codes</em>, not the data which function is supposed to return. Is there any use case of using return codes to indicate success / failure, or no use case? That will help me understand better.</p> <p>One use case of exceptions what I have understood from "Zdeslav Vojkovic" is when the callee function wants to compulsorily notify caller function of some condition and interrupt the caller execution. In the absence of exception, the caller may or may not choose to examine the return codes. But in case of exceptions, the caller function must necessarily handle the exception, <em>if it wants to continue execution</em>.</p> <p><strong>EDIT:</strong></p> <p>I had another interesting idea. Any callee function which wants to support the idea of caller function recovering from its error can raise event, and check the event data after the event has been handled, and then decide to throw or not to throw exception. Error codes will not be used at all. Exceptions will be used for unrecovered errors. Basically when a callee function is unable to do what its contract says, it asks for "help" in the form of any available event handlers. Still if it is not able to perform the contract, it throws an exception. The advantage is that the added overhead of throwing exceptions is reduced, and exceptions are thrown only when the callee function or any of its caller functions are not able to recover from the error.</p> <p>Suppose if the caller function does not want to handle the error, but rather the caller's caller function wants to handle the error, the custom event dispatcher will ensure that event handlers are called in the reverse order of event registration, i.e. the most recently registered event handler should be called prior to other registered event handlers, and if this event handler is able to resolve the error, the subsequent event handlers are not at all called. On the other hand, if the most recent event handler can not resolve the error, the event chain will propagate to the next handler.</p> <p>Please give feedback on this approach.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload