In C#, is there any way to throw a warning, like the ones the compiler gives you? Sort of like an exception, only not a fatal error, and the function can continue? For example, in my my connection sanity, I'd like to do something like this:
// Check for an illegal client.
if (!( m_sClient.Equals("RATS") || m_sClient.Equals("PXES") || m_sClient.Equals("NB2W") || m_sClient.Equals("VD2D") ||
m_sClient.Equals("PX2D") || m_sClient.Equals("3RAW") || m_sClient.Equals("PX3W")))
throw new ArgumentOutOfRangeException(null, "You have not selected a valid client. See the readme for more information.");
// LOOK AT ME
if (m_sClient.Equals("RATS") || m_sClient.Equals("PXES"))
throw new ConnectionWarning("StarCraft and Brood War are currently subject to checks by Blizzard's Wardent technology, "
+ "causing possible disconnections after a few minutes.");
// LOOK AT ME
// Check if they're attempting to use an SPR-related client (unsupported).
if (m_sClient.Equals("3RAW") || m_sClient.Equals("PX3W"))
throw new ArgumentOutOfRangeException(null, "The product you have selected has not had it's logon method implemented.");
(See the LOOK AT ME part in the middle)
Does anyone know of a way to do this?
I think you really need to take a look at your design. Should something so deep as your connection, which has several layers of abstraction, be communicating with your user interface in such a high level? Probably not.
Exceptions are supposed to be raised in exceptional circumstances. Clearly this isn't such a case.
An alternative might be to create a "Warning" event:
// outside of classes
public delegate void WarningEventHandler(object sender, WarningEventArgs e);
public class WarningEventArgs : EventArgs
{
private string m_msg;
public WarningEventArgs(string warning)
{
m_msg = warning;
}
public string Message { get { return m_msg; } }
}
// in the class
[field: NonSerialized]
public event WarningEventHandler Warning;
protected virtual void OnWarning(WarningEventArgs e)
{
if (Warning != null)
Warning(this, e);
}
// in your method
if (string.Compare(m_sClient, "RATS", true) == 0 || string.Compare(m_sClient, "PXES", true) == 0)
OnWarning(new WarningEventArgs("Starcraft and Brood War..."));
Quote from: Joex86] link=topic=10676.msg136245#msg136245 date=1195498394]
// Check for an illegal client.
if (!( m_sClient.Equals("RATS") || m_sClient.Equals("PXES") || m_sClient.Equals("NB2W") || m_sClient.Equals("VD2D") ||
m_sClient.Equals("PX2D") || m_sClient.Equals("3RAW") || m_sClient.Equals("PX3W")))
throw new ArgumentOutOfRangeException(null, "You have not selected a valid client. See the readme for more information.");
...
// Check if they're attempting to use an SPR-related client (unsupported).
if (m_sClient.Equals("3RAW") || m_sClient.Equals("PX3W"))
throw new ArgumentOutOfRangeException(null, "The product you have selected has not had it's logon method implemented.");
Why is it that at first you call
3RAW and
PX3W invalid... and then proceed to mention that you can't login with them? Wouldn't it make sense that since they don't exist, their login method doesn't exist either?
You should probably stop having all that sex, it's making you retarded.
A good program should simply pick the reversed 4-letter names for the products and... reverse them back on its own. Don't rely on telling the user to pick a 'real' product because as far as they're concerned, RATS could very well be what they used in another program, so they'll just go back to it.
Quote from: Newby on November 19, 2007, 07:46:24 PM
Why is it that at first you call 3RAW and PX3W invalid... and then proceed to mention that you can't login with them? Wouldn't it make sense that since they don't exist, their login method doesn't exist either?
You should probably stop having all that sex, it's making you retarded.
You should get laid. You missed the not operation.
Quote from: Newby on November 19, 2007, 07:46:24 PM
A good program should simply pick the reversed 4-letter names for the products and... reverse them back on its own. Don't rely on telling the user to pick a 'real' product because as far as they're concerned, RATS could very well be what they used in another program, so they'll just go back to it.
I'm really touched that you approve of my coding. (http://felbot.googlecode.com/svn/trunk/Felbot/frmConfig.cs)
Quote from: Joex86] link=topic=10676.msg136301#msg136301 date=1195541994]
Quote from: Newby on November 19, 2007, 07:46:24 PM
Why is it that at first you call 3RAW and PX3W invalid... and then proceed to mention that you can't login with them? Wouldn't it make sense that since they don't exist, their login method doesn't exist either?
You should probably stop having all that sex, it's making you retarded.
You should get laid. You missed the not operation.
Quote from: Newby on November 19, 2007, 07:46:24 PM
A good program should simply pick the reversed 4-letter names for the products and... reverse them back on its own. Don't rely on telling the user to pick a 'real' product because as far as they're concerned, RATS could very well be what they used in another program, so they'll just go back to it.
I'm really touched that you approve of my coding. (http://felbot.googlecode.com/svn/trunk/Felbot/frmConfig.cs)
You should be touched, because I don't approve of it.
Horrible.
F
Quote from: Warriorx86] link=topic=10676.msg136305#msg136305 date=1195570177]
You should be touched, because I don't approve of it.
You're saying you touch Joe? Homo pedophile.
Quote from: Warriorx86] link=topic=10676.msg136305#msg136305 date=1195570177]
Horrible. F
K maddox.
Quote from: MyndFyrex86/64] link=topic=10676.msg136313#msg136313 date=1195586693]
Quote from: Warriorx86] link=topic=10676.msg136305#msg136305 date=1195570177]
You should be touched, because I don't approve of it.
You're saying you touch Joe? Homo pedophile.
Quote from: Warriorx86] link=topic=10676.msg136305#msg136305 date=1195570177]
Horrible. F
K maddox.
party poopers poop at parties.
I prefer to read and write the product id as a DWORD, so I can switch() on it.
Quote from: Camel on November 20, 2007, 08:06:40 PM
I prefer to read and write the product id as a DWORD, so I can switch() on it.
Good thing that C# can switch on strings. :)
Quote from: MyndFyrex86/64] link=topic=10676.msg136343#msg136343 date=1195616254]
Quote from: Camel on November 20, 2007, 08:06:40 PM
I prefer to read and write the product id as a DWORD, so I can switch() on it.
Good thing that C# can switch on strings. :)
Oh. Hehe. Thanks for telling me that a few months ago. :P
The purpose of a switch statement is to avoid giving bias to the options at the top of the if..else if.. tree. Allowing a switch statement to accept anything beyond constant integer base types for its cases is just silly.
Quote from: Joex86] link=topic=10676.msg136301#msg136301 date=1195541994]
You should get laid. You missed the not operation.
So if they enter "STAR" or "SEXP" it'll say invalid product? That's just as retarded. :|
Quote from: Camel on November 20, 2007, 11:02:26 PM
The purpose of a switch statement is to avoid giving bias to the options at the top of the if..else if.. tree. Allowing a switch statement to accept anything beyond constant integer base types for its cases is just silly.
Huh? That doesn't make any sense! An if/else tree with non-overlapping cases gives no bias, so that reason makes no sense.
The reason you use a switch/case is purely speed and style.
Quote from: Newby on November 21, 2007, 12:21:02 AM
Quote from: Joex86] link=topic=10676.msg136301#msg136301 date=1195541994]
You should get laid. You missed the not operation.
So if they enter "STAR" or "SEXP" it'll say invalid product? That's just as retarded. :|
See the link. They click StarCraft or StarCraft Expansion in the config dialog. You may notice that I switched the direction of all the product codes after posting this.
Quote from: iago on November 21, 2007, 08:32:13 AM
Quote from: Camel on November 20, 2007, 11:02:26 PM
The purpose of a switch statement is to avoid giving bias to the options at the top of the if..else if.. tree. Allowing a switch statement to accept anything beyond constant integer base types for its cases is just silly.
Huh? That doesn't make any sense! An if/else tree with non-overlapping cases gives no bias, so that reason makes no sense.
The reason you use a switch/case is purely speed and style.
No, an if/else tree evaluates the conditions in the order they appear. A switch table with constant base types as its cases uses a jump table, which more appropriate for this case.
In any event, for this particular example, where this code is executed once per execution, it is hardly worth arguing over. As a matter of principle, however, you should at least be aware of how each one works.
Quote from: Camel on November 21, 2007, 08:36:36 PM
No, an if/else tree evaluates the conditions in the order they appear. A switch table with constant base types as its cases uses a jump table, which more appropriate for this case.
In any event, for this particular example, where this code is executed once per execution, it is hardly worth arguing over. As a matter of principle, however, you should at least be aware of how each one works.
I don't think you quite understand the principle behind the different constructs.
The only reason your statement holds true is because switches are forced, by the browser, to have different values. But that's just a side effect of its structure, not the reason for it.
I love how horribly off-topic this became. It makes me fuzzy and gleeful inside.
Joe: since your question was already answered, I wouldn't consider this going off topic.
Quote from: iago on November 21, 2007, 08:46:17 PM
The only reason your statement holds true is because switches are forced, by the browser, to have different values. But that's just a side effect of its structure, not the reason for it.
I'm not sure what your point is. Can you elaborate?
All I'm trying to say is that, where a switch can be used, and where there are more cases than double the number of operations it takes to evaluate input-to-address of the jump table, it's exclusively faster to use a switch construct, except with cases where my assumptions (such as the way a switch reduces to a jump table) don't hold true, and where the first options in the if/else tree are to occur more often than the latter options.
That is one of the longest non-run-on sentences I've ever written.
except that an optimizing compiler would choose whether to use a jump table or explicit per-case evaluation regardless of whether you use if-elses or switch or even nested ifs. Your statement is flawed; iago is correct in stating that you seem to not understand what it's for.
The "let the optimizer figure it out" defense is invalid, regardless of whether you are correct or not. It takes a fool to assume that a compiler will have an optimizer, or that it will behave in any specific way. Even so, choosing an if/else tree where it is logical to use a switch() construct will not help the compiler figure out how to optimize it, because a switch() construct's purpose is more obvious than a tree of if/else statements.
If you read what I posted, you'll see that I said my assumptions include that switches reduce to jump tables, while if/else trees do not. This assumption is based off of several experimental benchmarks I did in which agreed with me. It seems to me that you are trying a little too hard to read between the lines, when in reality I do not speak in tongues.
Quote from: Camel on November 22, 2007, 12:33:48 AM
Joe: since your question was already answered, I wouldn't consider this going off topic.
Quote from: iago on November 21, 2007, 08:46:17 PM
The only reason your statement holds true is because switches are forced, by the browser, to have different values. But that's just a side effect of its structure, not the reason for it.
I'm not sure what your point is. Can you elaborate?
All I'm trying to say is that, where a switch can be used, and where there are more cases than double the number of operations it takes to evaluate input-to-address of the jump table, it's exclusively faster to use a switch construct, except with cases where my assumptions (such as the way a switch reduces to a jump table) don't hold true, and where the first options in the if/else tree are to occur more often than the latter options.
That is one of the longest non-run-on sentences I've ever written.
It seems that you changed your story from your other posts. Suddenly, the point is to use a jump table, not to force mutual exclusion. Nice try, though!
If you thought I cared about mutual exclusion, then clearly I mislead you in my other posts. From my first response to MF, I can see how you could have made false assumptions about what I meant, but in my second post I pointed out that an if-else tree is inherently less efficient than a jump table for states that have many transitions, so I'm not sure how you could possibly have been mislead.
If you think about an if-else tree that does not enforce mutual exclusion analytically, in terms of states and transitions, you would not be describing a single state with many transitions, you'd be describing multiple states with multiple transitions. Some of those states might be unreachable due to circumstance, or even have no transitions whatsoever (consider: if(false){...} for example).
I could just as well argue that the mutual exclusion rule is a product of the way jump tables work, because the switch/case construct was designed as an aide for the compiler. The rules which apply to its manifestation in the code layer are a product of the way it is implemented in the assembly/bytecode layer.
Any decision of the compiler to replace a switch/case construct with if-else-style assembly/bytecode, and any decision of the compiler to replace an if-else tree construct with a jump table is an optimization, which is not something you can rely on in any condition where you care that there is a difference.