Click here to Skip to main content
15,867,453 members
Please Sign up or sign in to vote.
3.00/5 (1 vote)
See more:
VB
Module Module1

    Sub Main()
        Dim Input As String
        Console.WriteLine("If Cube Input 1")
        Try
            Input = Console.ReadLine()
            If Input = ("1") Then
                Dim Side As String
                Console.WriteLine("Input the value of the side")
                Side = Console.ReadLine()
                Dim C As Integer
                C = Side * Side * Side
                Console.WriteLine(C)
            End If
        Catch ex As Exception
            Console.WriteLine("That selection dosent exist please try again")
        End Try
        Console.Read()
    End Sub

End Module


Im trying to get a message to appear after the user puts in the wrong input but i cant seem to get it to work. The error does work but it dosent give a message to the user. What Am i doing Wrong?
Posted
Comments
joshrduncan2012 18-Dec-13 16:37pm    
Have you tried turning on the debugger to step through the code to see what kind of path it is taking?

You never "throw" the error anywhere, so it is never raised. Look at how to raise exceptions for throwing them.

But...

This is really an abuse of exceptions. You could simply use an "if" statement to determine if the user has inputted an invalid value. Using exceptions for this isn't what exceptions are meant to do. If you can handle something, handle it, otherwise you can throw exceptions for something higher up to handle it. Unhandled user exceptions are a really nasty surprise for your user.

On top of that, raising and handling exceptions is expensive and can really slow your application down. This might not be visible in the little console application you are doing, but when you graduate to bigger things you'll really start to regret using exceptions to validate user input.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 18-Dec-13 17:23pm    
Ron, did you read original authors who invented exceptions (Barbara Liskov at al.)? Exceptions are not errors. Classical example: reactor overheat. Using exception for non-errors is a subject of a heated debate, but simple reasoning can proof that in many cases it is very practical to throw exception on invalid input. This is one of the things exceptions were really designed for, and such techniques are successfully and legitimately used.

"Slow" argument is also not valid in this case, but should be taken into account for other cases. By the way, did you timed "try" and propagation of exceptions. Even try is amazingly fast on modern CPU architectures; as to propagation, it's stack unwinding, also very fast...

—SA
Ron Beyer 18-Dec-13 17:37pm    
Sergey, I will read that but you are right, it is a heated debate and I lie on the side that exceptions should be used rarely and only thrown if the immediate code can't handle the problem at hand. In this case though, you have to admit that a much better approach would be to simply use an if/else to validate input.

If the assignment at hand required the use of exceptions as a demonstration that's different, but it wasn't clear in the original question that demonstrating using exceptions was the goal of the excercise...
Sergey Alexandrovich Kryukov 18-Dec-13 18:11pm    
About if? Not always. Exception were created to greatly simplify code and isolate the "regular" behavior from exceptional. User's mistake is a clear case of such exceptional behavior. As to "if", again: it depends. Sometimes it is better to "if", sometimes not. I think I do understand the situation, because I was the very early developer of the fully-fledged exception handling on CPU-level, at the time when exceptions were not yet introduced in C++. (It might give your the reason to state that I'm "biased", but I don't think so; I first realized the importance of exceptions, and only much later implemented them.) I think, this is what happen: a big part of community, computer-science teacher and other people did not full understand the idea. But those who did pushed it to make a commonplace. Those who did not tried to be careful and recommended to limit the use of exceptions. Later on, when exceptions became a commonplace, many of those teachers understood it well, but did not want to loose face and accept their former bias.

Of course, what I say don't proof anything. The matter could be explained on the base of some use cases people would agree on or not. Then one could explain the benefits of throwing exceptions, and another could explain the real problem, but the explanation should be logical, free from arguments like "common practice", opinions, etc.

As to the "rare" use, things should not be mixed up: the handling of exceptions should really be rare, located to the points which I call the "points of competence". It does not mean that throwing should be rare of frequent. Anytime the situation cannot be perfectly resolved in the local context, exception should be thrown. The user input error can be one of such cases; examples are obvious: the user input, say, string, but in the context of data input, the system reaction to the error is unknown, because it's utterly impractical to keep all versions of error message in the context where the data is entered...

As to the goal of exercise: see the OP's "solution". It's clear that OP is not the one making decisions. "Requirement". I usually deny to answer any further is such situations, just don't want to waste time on a non-principle player. In tern, is someone requires something without proper motivation, this "someone" should be responsible for answering.

—SA
Ron Beyer 18-Dec-13 19:19pm    
I think we are on the same page in a lot of respects and I'm just not saying it well. I agree that handling exceptions is the "rare" case, but throwing them is fine as required. What I would really disagree with is throwing an exception inside a try/catch and handling it in the catch. This isn't so bad in the case of the OP, but extrapolate this to reading a large binary file, throwing and catching in a loop where another programming construct could otherwise handle it is computationally expensive.

I agree that exceptions should only be thrown if the current context can't handle the error and continue processing. I'm all for throwing as many exceptions as make sense to throw. I'll continue studying exceptions but I do think we are in the same boat at least, even if we are using different oars :).

Sergey Alexandrovich Kryukov 18-Dec-13 19:40pm    
Oh... yes, there are usual cases when throwing inside try is needed directly (indirectly it always happens if exception are handled at all), and rare cases what such throwing should be done from the catch.

This is a delicate moment, I can explain it for just one case. Here is the case: you have general exception, such as integer division by zero, so you can say "Attempt to divide by zero". But this is not always informative. It happens when you do A or when you do B, and you want really say "Problem is A". Or in B. One of the comprehensive ways to do it is: catch "general" exception and re-throw from inside "catch", but not this exception, but "specialized", "application-level" exception. The "divide-by-zero" exception can be passed along as an internal exception. This way, you combine two different "points of competence" one point gets information on "technologically fundamental" exception (integer divide-by-zero) and another point up-stack — "application-level", "semantic" exception. This way, you avoid increase of informational entropy seeded by exception at the secondary handle point, where you have two exception instances instead of one, with information on both aspect. It will allow you to say "Problem in A, the problem is [different reasons come here]".

Did you use this technique? It's not needed everywhere, but when needed, it is very robust.

—SA
I had to rearrange my code a bit but i have figured it out my self here it is
VB
Module Module1

    Sub Main()
        Dim Input As String
        Console.WriteLine("If Cube Input 1")
        Input = Console.ReadLine()
        If Input = ("1") Then
            Try
                Dim Side As String
                Console.WriteLine("Input the value of the side")
                Side = Console.ReadLine()
                Dim C As Integer
                C = Side * Side * Side
                Console.WriteLine(C)
            Catch ex As Exception
            Finally
                Console.ReadKey()
            End Try
        End If
    End Sub
End Module

I had an assignment that required me to use exceptionin this way
 
Share this answer
 
Comments
Ron Beyer 18-Dec-13 17:19pm    
You aren't using the exception though, you are just ignoring it now. Plus I'm sure what you wrote up there won't compile as you can't multiply strings together.
TnTinMn 18-Dec-13 19:29pm    
Unfortunately, his code will compile if "Option Strict" is off. I really wish MS would have depreciated these hold overs from VB6 when they depreciated the "Microsoft.VisualBasic.Compatibility.VB6" Namespace. I can understand their desire to provide an upgrade path, but it has been long enough. Or at the very least, set the VB IDE defaults to have Option Strict, Option Explicit "On" and Option Infer "Off. It would eliminate many problems for all.

Sergey Alexandrovich Kryukov 18-Dec-13 19:41pm    
Agree. Non-strict behavior is poor evil.
—SA
Ron Beyer 18-Dec-13 19:44pm    
When I was a VB programmer I always made sure option strict/explicit was on, I would hope that people would do the same but I guess not. Another evil part of VB I guess. Thanks for reminding me.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900