The $30k Web App



  • @b-redeker said:

    @Cat said:

    And VB6 not only allows but in certain unusual cases requires "On Error Goto Next"; there are certain errors that do not get caught with On Error Goto label.
     

    This I didn't know (and I've spent many years with VB and have done unmentionable things with it). I seem to remember some instances where normal programming wouldn't catch an error; I think with the common dialog you need to have an on error goto to handle the case where a user cancelled the dialog. But I've never seen a case where on error goto label wouldn't work and on error resume next would.

    However, http://msdn.microsoft.com/en-us/library/5hsw66as%28VS.80%29.aspx tells me:

    @MSDN said:

    The On Error Resume Next construct may be preferable to On Error GoTo when handling errors generated during access to other objects. Checking Err after each interaction with an object removes ambiguity about which object was accessed by the code. You can be sure which object placed the error code in Err.Number, as well as which object originally generated the error (the object specified in Err.Source).

    That doesn't mean what you think it does, they aren't saying that On Error Resume Next works better.  They are saying that if you have many calls to things that may error, On Error Resume Next allows you to deal with them one call at a time, while On Error GoTo dumps them all to the same error handling routine.  Since VB6 doesn't allow you to nest error handlers and doesn't have a good way to tell you where an error occurred, this may be a bad thing.


  • @blakeyrat said:

    Nope, sorry. From the other thread, we know it's impossible to dislike C++'s features without being "too dumb to write C++." The only logical conclusion to draw here is that you're simply too dumb to write VB.net. Sorry.

    Of course! Why didn't I think of tha...oh, right. Too dumb.



  • @Jaime said:

    Complaining about VB because of the atrocities you've seen committed in it is like not liking people because of the language they speak.  Let me give you an example:

    Bob is a bigot.  Bob's only exposure to Spanish speaking people has been being mugged by gang members speaking Spanish, losing a menial job due to competiton from illegal workers that speak Spanish, and all of the Spanish speaking people that rob the public health care system on his dime (Bob's perspective, of course).  Bob thinks that all Spanish speaking people are lazy law breakers that want his money.  Bob thinks the world would be a better place if the Spanish language was banned.

    That rediculous story is a very close parallel to your argument against VB.  The term "VB code monkeys" is as close to a racial slur as you can get on a topic other than race.  BTW, Microsoft has not only not killed VB, but they have committed to introducing new language features in VB and C# simultaneously.

    Not sure if serious...



  • @Bulb said:

    @Jaime said:

    BTW, Microsoft has not only not killed VB, but they have committed to introducing new language features in VB and C# simultaneously.

    In fact VB.NET and C# are not separate languages. They are just two syntaxes for the same language. You can, using standard .NET components (System.CodeDom.Compiler), parse VB and write it back as C# and vice versa.
    I used to be unaware of this until the aforementioned switcheroo on platforms forced me to learn .NET. Having dealt with a couple of VB.NET code, I have found out that it is in fact C# with a goofy syntax. Hell, I already mentioned that before!

    The platform itself has a couple of WTFs, one of the worst is the lack of checked exceptions, so lazy programmers are encouraged to follow the infamous Diaper Pattern the first time they get fed up with a zillion exceptions coming from god knows where. Checked exceptions at least ensure that you will either handle the exception, or throw it up to the caller that will handle it instead. I've had a couple of people complain that my code throws a couple of specific Exceptions (such as FailedPaymentException) because they actually expect me to swallow any Exception. Huh?

    And well, keeping VB in a strange state on .NET has also lead to some classic WTFs, some of them  have even made it to the frontpage (search for "Way to go O.O!") because VB6 devs insist on hacking "the VB6 way" into VB.NET.



  • @b-redeker said:

    This I didn't know (and I've spent many years with VB and have done unmentionable things with it).

     

    I don't recall exactly what caused those errors, but yes there were certain errors that would simply crash the client rather than go to the error handler.  It was a problem my company ran into, and one which ultimately led to millions of dollars in productivity lost when we had to rewrite error handling throughout our applications.  I was hired later, though, and only heard about this fiasco after the fact.



  • @danixdefcon5 said:

    my code throws a couple of specific Exceptions (such as FailedPaymentException
     

    From the name of it, that doesn't sound like something you want to throw, or even use an exception for.

    I mean, let's say your application is an accountant guy who gets things done, and something like a payment fails; do you want him to start screaming, drop to the floor and shit his pants forcing him to cease all work, OR do you want him to notice it, think of a course of action, come to your desk, calmly yet firmly explain the situation, then walk away and continue with the things he had to do?

    But perhaps I misunderstand how you let the program handle things.


  • :belt_onion:

    @bannedfromcoding said:

    @bjolling said:
    Why didn't they migrate to ASP.NET MVC?

    @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET(...)


    You conveniently snipped the line where to OP said, they [b]moved all code to page_load[/b]. Page_Load doesn't even exist in ASP.NET MVC.
    They migrated to ASP.NET Webforms which doesn't support the MVC pattern very well.


  • :belt_onion:

    @Bulb said:

    @bjolling said:

    Going from Java to .NET is not a WTF.

    Yes, it is. Just as going from Java to .NET would be. As long as the old code was working, the platform it used is still supported and the new platform is not revolutionary better, starting from scratch is throwing money out of the window.

    It can take almost zero advantage of the work done on the old version, usually having all the bugs that were already fixed or worked around in the old version and taking as long as the old version did to develop. On the other hand refactoring tends not to reintroduce problems and they can be fixed early since working version is available throughout, which can even be deployed if the need arises. So unless the new platform makes development, operation or maintenance that much cheaper, it does not pay to switch.

    I probably should have phrased that better, because in the context of the OP you're clearly correct.

    You would have to read my line with the assumption that the company had good reasons to discontinue Java in their environment. In that context, choosing .NET as a replacement for Java is not a WTF. But rewriting a Java MVC application as an ASP.NET Webforms application was TRWTF for me, especially knowing that Microsoft has also released an ASP.NET MVC framework



  • @Bulb said:

    @Jaime said:

    BTW, Microsoft has not only not killed VB, but they have committed to introducing new language features in VB and C# simultaneously.


    In fact VB.NET and C# are not separate languages. They are just two syntaxes for the same language. You can, using standard .NET components (System.CodeDom.Compiler), parse VB and write it back as C# and vice versa.

    There do have their differences, some stuff can't be expressed in either of them (C# couldn't define optional parameters before 4.0 and still can't define named indexer).

    And while the System.CodeDom seems to have an implementation for parsing code they actually throw a NotImplementedException() so at the moment there is no standard .NET way to parse code back.



  • @bjolling said:

    @bannedfromcoding said:
    @bjolling said:
    Why didn't they migrate to ASP.NET MVC?

    @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET(...)


    You conveniently snipped the line where to OP said, they moved all code to page_load. Page_Load doesn't even exist in ASP.NET MVC.
    They migrated to ASP.NET Webforms which doesn't support the MVC pattern very well.

    Yes, and that's one of the parts making up the WTF.

    You asked "Why didn't they migrate to MVC?" while OP clearly states that they were supposed to, just like they were supposed to use C#. They just crapped out an app that totally didn't fit the spec and got paid, thus we have a WTF.



  • @dhromed said:

    From the name of it, that doesn't sound like something you want to throw, or even use an exception for.

    Why not?

    @dhromed said:

    OR do you want him to notice it, think of a course of action, come to your desk, calmly yet firmly explain the situation, then walk away and continue with the things he had to do?

    How does using an exception prevent this?

    @dhromed said:

    But perhaps I misunderstand how you let the program handle things.

    Or the intent of exceptions. Is there a law somewhere that says exceptions should only be used for technical faults?


  • :belt_onion:

    @bannedfromcoding said:

    @bjolling said:
    @bannedfromcoding said:
    @bjolling said:
    Why didn't they migrate to ASP.NET MVC?

    @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET(...)


    You conveniently snipped the line where to OP said, they moved all code to page_load. Page_Load doesn't even exist in ASP.NET MVC.
    They migrated to ASP.NET Webforms which doesn't support the MVC pattern very well.

    Yes, and that's one of the parts making up the WTF.

    You asked "Why didn't they migrate to MVC?" while OP clearly states that they were supposed to, just like they were supposed to use C#. They just crapped out an app that totally didn't fit the spec and got paid, thus we have a WTF.

    Well, it was difficult to judge for which side your were arguing with you not arguing and all that :-)

    But it gets better, I just realized that you CAN have a Page_Load in ASP.NET MVC. In fact ASP.NET MVC can use almost every feature from 'classic' ASP.NET Webforms except for ViewState (but I'm sure one of you will find a blog that explains how to use Viewstate in ASP.NET MVC).



  • @dhromed said:

    @danixdefcon5 said:
    my code throws a couple of specific Exceptions (such as FailedPaymentException)

    From the name of it, that doesn't sound like something you want to throw, or even use an exception for.

    I mean, let's say your application is an accountant guy who gets things done, and something like a payment fails; do you want him to start screaming, drop to the floor and shit his pants forcing him to cease all work, OR do you want him to notice it, think of a course of action, come to your desk, calmly yet firmly explain the situation, then walk away and continue with the things he had to do?

    But perhaps I misunderstand how you let the program handle things.

    I'd rather he notice that something went wrong, stop doing what he was about to do (since he can't do it anymore), let me know about it, and let me decide what I want to do about it. Keep the logic of what to do when the payment fails out of the payment processor itself, since you may want different things based on what context it's being called in.

    For example, let's say that I have an application that has two different ways of processing payments, one at a time through a web interface, or nightly in unattended batches. Let's say that the method processPayment() returns a confirmation number if it succeeds or throws a FailedPaymentException when something goes wrong. The web client that calls it can display a formatted error message to the user and let them verify their data and try again. The batch job can loop through the batched payments, catch any exceptions thrown in an array, generate a report showing the transaction numbers for processed payments and a separate list of the failed payments, and send an E-mail message with that report attached.

    By keeping the what-to-do-on-failure logic out of the method that tries to do a concrete task, you keep that method simple and unit-testable. If you add another way that a user can initiate a payment process (say, through a GUI), you don't have to add more special cases to processPayment(). Instead, you handle failure in the GUI.

    davidh



  • @Jaime said:

    However, since you brought it up, it's strange that the C# guys are bringing up On Error Resume Next as an evil feature of VB6.  On Error Resume Next allows error handling very similar to traditional C error handling.  In modern terminology, C functions gave a "no-throw guarantee" and often indicated success or failure by setting a global variable named "errno".

     

    While there are plenty of C errors you can happily ignore if that's your thing, there are plenty of other errors which can crash your computer, or do nothing, or make demons fly out of your nose given suitable hardware support. Normal C error handling involves checking the return code of everything; errno is just there for when you know an error has occurred and need to check which one it was for some reason.




  • @__moz said:

    @Jaime said:

    However, since you brought it up, it's strange that the C# guys are bringing up On Error Resume Next as an evil feature of VB6.  On Error Resume Next allows error handling very similar to traditional C error handling.  In modern terminology, C functions gave a "no-throw guarantee" and often indicated success or failure by setting a global variable named "errno".

     

    While there are plenty of C errors you can happily ignore if that's your thing, there are plenty of other errors which can crash your computer, or do nothing, or make demons fly out of your nose given suitable hardware support. Normal C error handling involves checking the return code of everything; errno is just there for when you know an error has occurred and need to check which one it was for some reason.


    C functions indicate error by return value or setting an outbound pointer parameter to some error code; only after a problem is signalled that way errno will say anything meaningful, and functions that don't do extended error reporting don't set errno at all. And remember, successful function DOES NOT reset errno to 0. It may contain any random error code from older failure, or complete garbage. Check return value, read documentation, drink more vodka.



  • @dhromed said:

    @danixdefcon5 said:

    my code throws a couple of specific Exceptions (such as FailedPaymentException
     

    From the name of it, that doesn't sound like something you want to throw, or even use an exception for.

    I mean, let's say your application is an accountant guy who gets things done, and something like a payment fails; do you want him to start screaming, drop to the floor and shit his pants forcing him to cease all work, OR do you want him to notice it, think of a course of action, come to your desk, calmly yet firmly explain the situation, then walk away and continue with the things he had to do?

    But perhaps I misunderstand how you let the program handle things.

     

    Exception doesn't mean the user's program has to crash with an error. Code can catch and handle exceptions without the user ever becoming aware that they happened.

    Personally, for payment failed, I think an exception is the right method of signaling an error, because it prevents the caller from simply ignoring the failure and continuing on; the caller either needs to catch and handle the exception, or the caller will terminate with an error.



  • @bannedfromcoding said:

    C functions indicate error by return value or setting an outbound pointer parameter to some error code; only after a problem is signalled that way errno will say anything meaningful, and functions that don't do extended error reporting don't set errno at all.

     I know. My point was that being able to ignore some of the errors a C program produces is nothing like being able to ignore all of the errors a VB program produces.

    @bannedfromcoding said:

    And remember, successful function DOES NOT reset errno to 0. It may contain any random error code from older failure, or complete garbage.

    Having gone through the process of trying to write a robust script for MS SQL Server 2000 (which uses a mixture of aborting and setting a special variable for error tracking, and does reset the variable whenever something works), I can only be grateful for that fact.


Log in to reply