Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you mean something like ...</p> <pre><code>public Exception MyMethod( string foo ) { if( String.IsNullOrEmpty() ) { return new ArgumentNullException( "foo" ); } } </code></pre> <p>... rather than ...</p> <pre><code>public void MyMethod( string foo ) { if( String.IsNullOrEmpty() ) { throw new ArgumentNullException( "foo" ) } } </code></pre> <p>Then absolutely not, it is not okay to do that. You would be completely re-inventing the purpose of an exception and using it as an hresult. Here are some standard <a href="http://msdn.microsoft.com/en-us/library/seyhszts(VS.71).aspx" rel="noreferrer">best practices</a>.</p> <p>Another good reason not to is that standard delegates would no longer match your method signature. So, for example, you could not use <code>Action&lt;string&gt;</code> on MyMethod anymore and would need to use <code>Func&lt;string,Exception&gt;</code> instead.</p> <p>@Andy, per comment, answer too long for a comment: Not really. Don't be so concerned about the caller. He should be being defensive in his design anyway. Think about the semantics of an Exception ... "The execution of this application will stop right here unless somebody knows what to do about this problem." If you can resolve the issue, you should resolve it. If you can't, you have to log it and throw it to the next level, because they may know exactly what to do.</p> <p>You should handle what you can handle and throw what you can't. By definition, the guy up the call stack has a broader view of the world than you. Your application needs to be resilient in it's ability to deal with exceptions and keep on going. They only way to do that is defensive coding and push issues up to higher levels of information to see if anything can be done.</p> <p>At the end of the day if the answer is "no", then log the problem to it can be understood, be a good citizen of the box and terminate the application gracefully and live to fight another day. Don't be selfish and try and hide errors for your caller. Be defensive and he will do the same. :)</p> <p>Check out the <a href="http://msdn.microsoft.com/en-us/library/dd203116.aspx" rel="noreferrer">Enterprise Library Exception handling block</a>. It think they really articulate a great vision for how to deal with exceptions throughout your architecture.</p>
    singulars
    1. This table or related slice is empty.
    1. POIs it bad practice to return Exceptions from your methods
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJP Alioto
    1. USJP Alioto
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POIs it bad practice to return Exceptions from your methods
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CONoting ofcourse that those should be `ArgumentNullException` instances... and secondly, that there is one exception (har har) where it is somewhat permissible, and that's if you happen to have an 'exception builder' method that constructs an exception for you so that you can throw it.
      singulars
      1. PO
      1. USjerryjvl
    2. COif using exceptions is a best practice... why do tryCast and TryParse exist? I assume internally they don't use a try catch, just good error handling and pass back success or failure? It seems to me exceptions were invented to represent a problem, throwing them is a method of using them, as is passing or returning. Of course you could just allow the caller to decide which way they would prefer it via a boolean parameter or a tryX version of the method.
      singulars
      1. PO
      1. USMaslow
    3. COI would also add; I think ideally, code should be written as to allow other developers to never need to catch exceptions. Exceptions should be thrown when the code is used incorrectly, also other than throwing the normal ArgumentExceptions types, you should create a new exception type and better explain the reason for the throw. Also add the XML comment for the throw...
      singulars
      1. PO
      1. USEric Schneider
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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