4 ms·

Error handling was terrible in VB, evidenced by the number of production VB apps that panic when clicking the wrong button or typing the wrong letters. Going f

Error handling was terrible in VB, evidenced by the number of production VB apps that panic when clicking the wrong button or typing the wrong letters. Going from knowing enough to prototype to professional quality development was very hard. You could always tell a VB app. Controls don't line up, windows either prevent resizing or do so badly, lots of redraw flicker, varying visual styles, and crashes on seemingly benign user input. Database operations are often performed with no expectation of failure, the network is assumed to never have a problem, security policy is inconsistent, etc. Perhaps some blame can be laid at the learning materials that emphasize the happy path and treat errors as a separate subject. I hated VB and am so glad it is almost gone.

cm2187 5y ago
> You could always tell a VB app. Controls don't line up, windows either prevent resizing or do so badly, lots of redraw flicker, varying visual styles, and crashes on seemingly benign user input. You are describing 1998 VB as much as 2022 html+javascript
- mschuster91 5y ago
  With the obvious joke (or sad fact) that VB6 apps used to run on, like, 64 MB RAM systems (or less, if you were targetting Windows CE and had that extended tooling in Visual Studio for it) - and today for your average Electron or whatever browser based "app" you need 4GB+ of RAM.
  - StillBored 5y ago
    64 MB RAM, not unusual for a high end desktop/dev machine in the late 1990's, but... VB6 (the last one) was 1998, same year as win98, which listed a 486+16M of ram as its system requirements. Which was a big step up from a W95 386 with 4M of ram. So one probably didn't want to run VB itself on those smaller machines, but the resulting apps definitely did, and those low end desktops were exactly what a lot of vb apps were running on.
- victorvosk 5y ago
  Not sure how much you are joking, but all the "apps were better in the 90s" blog posts overlook the absurd flexibility web apps have gained over the years. VB and its ilk were used to write apps that were used in a very specific way. Many times companies wrote apps not just their business use cases, but literally with the expectation of the hardware their users had in the office, the network they were on and who would be maintaining the machines. Ultra rigid user experiences, but still somehow were bug prone. Today its like, oh yeah, a user had an issue, they were searching our million record database on their smart toaster, one of the table columns weren't aligned correctly and it was slow to load.
zozbot234 5y ago
> Error handling was terrible in VB Really? All you need is On Error Resume Next . Dead simple.
- slfnflctd 5y ago
  Can't tell if you're joking or not, but this is hilarious regardless. I believe a more serious answer would be: You could easily trap the error number and make it pop up in a MsgBox, then decide what to do with each type of error. Complex objects or functions would often each need their own custom error handling code, but it wasn't hard to do.
  - skeeter2020 5y ago
    > You could easily trap the error number and make it pop up in a MsgBox What would a non-developer do after seeing an error number? Click OK and carry on? Might as well just resume next
    - slfnflctd 5y ago
      The MsgBox is there purely for debugging purposes, you take that line out before the software is put in front of users. A single object or function can generate multiple error numbers at different points & in different situations-- ideally you trap and handle them all (in varying ways depending on the type of error) during the debugging phase.
  - projektfu 5y ago
    Not hard to do, just hard to do well. You have On Error GoTo and On Error Resume Next. There is no indication that any particular statement will have an error. Even if it is obviously something that could error, you don't necessarily know what kind of error. The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.
    - gamblor956 5y ago
      Not hard to do, just hard to do well. The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing. So exactly like the current Javascript ecosystem then?

cm2187 5y ago

> You could always tell a VB app. Controls don't line up, windows either prevent resizing or do so badly, lots of redraw flicker, varying visual styles, and crashes on seemingly benign user input. You are describing 1998 VB as much as 2022 html+javascript

mschuster91 5y ago
With the obvious joke (or sad fact) that VB6 apps used to run on, like, 64 MB RAM systems (or less, if you were targetting Windows CE and had that extended tooling in Visual Studio for it) - and today for your average Electron or whatever browser based "app" you need 4GB+ of RAM.
- StillBored 5y ago
  64 MB RAM, not unusual for a high end desktop/dev machine in the late 1990's, but... VB6 (the last one) was 1998, same year as win98, which listed a 486+16M of ram as its system requirements. Which was a big step up from a W95 386 with 4M of ram. So one probably didn't want to run VB itself on those smaller machines, but the resulting apps definitely did, and those low end desktops were exactly what a lot of vb apps were running on.
victorvosk 5y ago
Not sure how much you are joking, but all the "apps were better in the 90s" blog posts overlook the absurd flexibility web apps have gained over the years. VB and its ilk were used to write apps that were used in a very specific way. Many times companies wrote apps not just their business use cases, but literally with the expectation of the hardware their users had in the office, the network they were on and who would be maintaining the machines. Ultra rigid user experiences, but still somehow were bug prone. Today its like, oh yeah, a user had an issue, they were searching our million record database on their smart toaster, one of the table columns weren't aligned correctly and it was slow to load.

zozbot234 5y ago

> Error handling was terrible in VB Really? All you need is On Error Resume Next . Dead simple.

slfnflctd 5y ago
Can't tell if you're joking or not, but this is hilarious regardless. I believe a more serious answer would be: You could easily trap the error number and make it pop up in a MsgBox, then decide what to do with each type of error. Complex objects or functions would often each need their own custom error handling code, but it wasn't hard to do.
- skeeter2020 5y ago
  > You could easily trap the error number and make it pop up in a MsgBox What would a non-developer do after seeing an error number? Click OK and carry on? Might as well just resume next
  - slfnflctd 5y ago
    The MsgBox is there purely for debugging purposes, you take that line out before the software is put in front of users. A single object or function can generate multiple error numbers at different points & in different situations-- ideally you trap and handle them all (in varying ways depending on the type of error) during the debugging phase.
- projektfu 5y ago
  Not hard to do, just hard to do well. You have On Error GoTo and On Error Resume Next. There is no indication that any particular statement will have an error. Even if it is obviously something that could error, you don't necessarily know what kind of error. The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.
  - gamblor956 5y ago
    Not hard to do, just hard to do well. The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing. So exactly like the current Javascript ecosystem then?