wallyhs's comments

You can only recover from such errors locally. The local context is not available in a global exception handler.

> Corruption is outside the state of this discussion.

Why? If corruption leads to an exception, it seems relevant. Corruption could be the application's own fault, it could be failing hardware, it could be someone trying to exploit a vulnerability. It could be anything - a result of undefined behavior. Sorry if I'm using the term loosely.

> If half your app just overwrote the other half of your app, no matter what we say here is going to make any difference.

If it overwrote the other half, it should crash immediately. I can't just display an error message and retry the operation in that case. If I don't know what exception I'm handling, how can I be sure that I won't cause more damage by handling it?

> The other part (and in my opinion the important part) of exception handling is ensuring your stack unwinds correctly.

That is not what I was referring to. A program can still get into an inconsistent state with exceptions. For example, if a function updates half of some data structure and then throws, that data structure may be left in an inconsistent state. Of course you should not write functions that way, but it is an easy mistake to make. Do you really want your app to keep running in an inconsistent state?

I'm looking at it from a defensive, assume-the-worse perspective. If my application is in an inconsistent state, it should cease running immediately. If my application does not know which state it is in, it must assume that it is in an inconsistent state.

> No, you shouldn't. What are you going to do any differently with that than you would FileIsLockedException or NetworkIsDownException or HarddriveIsCorruptException? You wouldn't do anything differently. Show the user the ErrorMessage in the dialog and allow them to restart whatever operation was in affect. Let them choose a shorter path, close Excel, plug their Ethernet cable back in, or whatever. Trying to play wack-a-mole is a fools errand.

I don't understand this viewpoint. If a file is locked, the user may be able to fix it, so go ahead and display an error. But if there is corruption, then what is the user going to do? You can't tell them, "Restore your system from backup, and then click OK." Your program has to crash before it causes more problems.

What if the situation is stack corruption or heap corruption? Or what if the error left the application in an inconsistent state? Continuing to run might corrupt the user's data. What if an attacker caused the corruption in order to gain unauthorized access? Logging or displaying the error might be exactly what they want.

I often see variations of this advice: If you don't know how to handle it, don't catch it. By definition, you don't know how to handle an unknown exception.

> Put MSDN away, you don't need it.

I think it is a good idea to understand the behavior and failure modes of every API function that you call; this requires that you consult the documentation.

It's not just about the grass. When trees die, they become hazards and must be removed. That's expensive. Without trees, there are fewer birds. There is no shade. The sound of leaves is absent from the wind. Obviously, there are more important things for a society to worry about, but my point is that this issue is not just about grass.

People seek out natural things such as plants. They put them in their homes, they hang paintings of them on their walls, and they decorate their cubicles with them. I don't think it is surprising that people want green lawns. It is depressing to live in a brown world.

The answer seems to be to design _better_ lawns: plant grasses, shrubs, and trees which grow naturally in the area, do not require huge amounts of water, and are drought-resistant. I don't know about LA, but, in my area, this transition has been underway for years.

Since the site is Enterprise Craftsmanship, I read it from that angle. In my experience, deployments must be requested several days in advance and require approvals from managers, testers, analysts, and functional experts. Quick "emergency" changes require extra approvals and are reviewed periodically. Minor configuration changes don't have nearly as many restrictions.

In that type of environment, I think it is absolutely worth the flexibility. And "building in" that kind of flexibility means to, um, add a line to the existing configuration file.

You omitted that from your comment, but I agree. I was just pointing out the option, because it didn't sound as if you had tried it.

I did not mean to endorse anything.

Instead of throwing away your project structure, try creating a "go" subdirectory in your project and setting GOPATH to point to it. Yes, you need a separate GOPATH for each project, but it's no worse than needing a separate Python virtualenv for each project.

No, but you seemed to imply that one can only learn from certain people in certain contexts. I find that I gain surprising insight from unexpected people at unexpected times. HN is not an exception.

> No, they can't, because the folks who are commenting at what you think is that level are actually completely unqualified to do so.

> The folks who are qualified to write articles and papers on the topics that might interest you, do exactly that.

How could you possibly know who is qualified and who is not? Given that the authors of submitted articles frequently comment on HN themselves, it must be true that at least some HN comments are made by qualified people. But that assumes that writing an article is the sole requirement for being "qualified". Not all articles are written by qualified people. Additionally, many articles are watered down by journalists, and HN threads can provide broader perspectives.

> There is no inherent value in wasting intellectual effort on an HN comment.

There is as much inherent value as there is in wasting intellectual effort in a conversation at a dinner party. If I am talking to someone whose life experience is completely different from mine, I am learning something even though they are not rising to the level of their capabilities. I am allowed to learn subjects superficially out of curiosity and without the blessing of an authority figure. I have to choose who to listen to and who to ignore just like I do with other sources of information such as HN submissions.

Asking for sources in response to an unfounded claim is common on HN. I've never seen anyone called naive, greedy, and lazy for it, though. At any rate, asking for a source does not preclude one from researching the topic separately.

I agree that HN should not be put on a pedestal. Neither should the submissions.

In my area, they use goats in town along heavily traveled bike and foot paths to control noxious weeds such as knapweed and leafy spurge. Goats are reported to be more effective than chemical herbicides and don't harm beneficial bugs, fungi, and bacteria. Children love to stop and watch the goats, too.

> Or are there some advanced Postgres features that I'm not aware of that would allow all these combinations in some kind of prepared statement?

I can't speak specifically to Postgres, but, in my experience, there is nearly always a way to do what you want with bound parameters. No advanced features are required. It often results in poor performance and redundant code that is hard on the eyes. You will get what you deserve, but sometimes you don't have a choice.

Here is an example of the horror:

    WHERE (:1 IS NULL OR :1 = item_id)
      AND item_num BETWEEN NVL(:2,0) AND NVL(:2,9999999999)
      AND item_date BETWEEN NVL(:3,'01-jan-1900') AND NVL(:3,'31-dec-4712')
      AND item_name LIKE NVL(:4,'%')
    ORDER BY
      CASE :5 WHEN 'NUM' THEN item_num WHEN 'DATE' THEN item_date ELSE item_name END,
      CASE :6 WHEN 'NUM' THEN item_num WHEN 'DATE' THEN item_date ELSE item_name END

Edit: I suppose you could also parameterize the ascending vs. descending sort, although I have never tried. My first thought is to duplicate each line in the ORDER BY clause: one bind parameter for ASC and another for DESC. Have each CASE return a constant if the bound value is NULL, and then bind NULL for the direction you do not want. Yuck.

I am not advocating any of this but am pointing out that bind parameters can be abused in surprising ways if you are backed into a corner.

Now I know where my bias comes from: I did not consider going wrong with semicolons in C. Perhaps that is because C is my oldest friend. You are of course correct that the C style is not perfect either. Thanks for the reply.

I am - I think - looking at this from a safe-by-default perspective. Everyone will forget to include a semicolon eventually as you pointed out, but shouldn't your default strategy be the safest one?

Maybe I am missing something. There are obviously cases where missing semicolons do cause problems. Is there a situation in which adding a semicolon where allowed causes problems or increases the chances of introducing a bug in the future?

Don't forget about the tooling: unit testing, benchmarking, generated documentation, code formatting, and emacs+vim plugins are included in the official package. I think these are often overlooked when describing its benefits. You can jump in and start working right away.

In discussions about error handling in Go, I rarely see mention of panic used for private exception handling. If a module exposes a small surface area, the public entry points can recover from panics and return them as errors. Private functions can then use panic to report errors:

  func PublicEntryPoint(input string) (output []byte, err error) {
    defer func() {
      if e := recover(); e != nil {
        output = nil
        err = e
      }
    }()
    err = nil
    output = privateFunc(input) // no need to check for error here
    return
  }
  func privateFunc(input string) []byte {
    foo := otherPrivateFunc(...) // no need to check for error here
    // ...
  }
  func otherPrivateFunc() int {
    // ...
    panic(fmt.Errorf("Something is wrong"))
  }

I would panic-recover a specific type of error instead of the generic "error" type, but I'm simplifying for the example. Also, it is not recommended to panic across module boundaries.

When I mentioned intent, I was mostly referring to the use of an "if" statement vs. short circuiting in the referenced example. But I mean it in general. Every code base is different, of course.

> If you use a no-semicolon style, though, you must name all your expressions.

Thanks, I guess I missed that point.

> No problems.

Except that there actually was a problem in this case as evidenced by the surrounding discussion. If the code had been written with a semicolon (or an if statement!) from the beginning, there never would have been a problem. You can argue that it wouldn't have been a problem if JSLint had been written "correctly" from the beginning, but every tool has bugs.

Code defensively, and don't get fancy unless you need to. You're not just complying with the language spec, you are communicating your intent to the other developers who will read and maintain your code.

From the conclusion at the end of the article:

"We aren’t going to abandon DVCSes. And honestly, at the end of the day, I don’t know if I want you to. I am, after all, still a DVCS apologist, and I still want to use DVCSes, because I happen to like them a ton. But I do think it’s time all of us apologists take a step back, put down the crazy juice, and admit, if only for a moment, that we have made things horrendously more complicated to achieve ends that could have been met in many other ways."

In the next paragraph, the author links to a post that explains how Facebook will soon experience productivity bottlenecks because of their repository size. That post also explains why they don't want to split up their repository and that, "..the idea that the scaling constraints of our source control system should dictate our code structure just doesn't sit well with us."

These are not UX gripes and the problems aren't solved by adding more cheap storage.

The complaints as I read them are:

* Large repository size because of blobs, large histories, or many files

* Difficulty of using git

* Pull requests aren't easier than patch bombs

Only the last one has to do with Github.

> If you implement in house then you've just given yourself an extra burden for the life of your project.

That is true, but maintaining third-party dependencies is also a burden for the life of your project, especially if your project outlives its dependencies. It may be well worth the burden in most cases, but it is not free.

If you are primarily using stored procedures, you are probably viewing the database as a "persistence API" with its own encapsulated logic.