Isaacs: try/catch is an anti-pattern - <AUTHOR> https://groups.google.com/d/topic/nodejs/1ESsssIxrUU <comment><USER2> Anybody who wants to judge try/catch should first go and read about Common Lisp's condition system. See for example the chapter about conditions and restarts from the excellent book "Practical Common Lisp" by Peter Seibel:

[http://www.gigamonkeys.com/book/beyond-exception-handling- co...](http://www.gigamonkeys.com/book/beyond-exception-handling-conditions- and-restarts.html)

Notice I'm not saying you should go and program in Common Lisp, just that you should understand those ideas before you engage in any sort of meaningful discussion about exceptions, errors and error handling in general. Because, you know, some things have already been thought about and invented. Don't re- invent them.

And on a more practical level, in languages with dynamic binding it isn't difficult to provide error handlers and "send" them up the call chain, so that in case of an exception your handler gets called, fixes the problem, and lets the called function continue. You can do all that using try/catch as a low- level tool, I've seen it done in Clojure, using JVM's exception system.

<comment><USER3> Inspired by Lisp's condition system I wrote a ruby library which comes pretty close to Lisp's error handling. It also implements "restarts" ... a little bit messy though since, as you said, low-level execption are used to get it working. In one point the condition system bootstraps itself which is quite interesting to think about.

<https://github.com/melkon/conditions>

An example ("parse_log_file" and "log_analyzer show restarts"): [https://github.com/melkon/conditions/blob/master/example/exa...](https://github.com/melkon/conditions/blob/master/example/example.rb)

In the beginning I thought it can only be ported to Ruby because I used some Ruby-specific features. The exception solution (which I implemented later) should work in a lot of different languages though.

Another thing is, if you understood the condition system, you can use it for a lot of different things besides error handling. You can build protocols on top of that, event handling etc. Freedom is yours.

<comment><USER4> Have you considered using Ruby's throw/catch instead of exceptions? I did that for Atomy's condition system[1]. They worked great because you can just use the restart names for the throw/catch tags.

[1]: [https://github.com/vito/atomy/blob/master/kernel/condition.a...](https://github.com/vito/atomy/blob/master/kernel/condition.ay)

<comment><USER3> I might have considered throw and catch as I wrote the library, but right now, I cannot think of any good reason why I haven't used it. Will check that again. Thanks for the suggestion.

</comment></comment></comment></comment><comment><USER5> This seems to be exactly the attitude of Go:

"We believe that coupling exceptions to a control structure, as in the try- catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.

Go takes a different approach. For plain error handling, Go's multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go's other features, makes error handling pleasant but quite different from that in other languages.

Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function's state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code."

<http://golang.org/doc/go_faq.html#exceptions>

In Go, if there's a programmer error, call panic(); if there's a non- programmer error, return it as a second return value.

[Added] Plus, it's obvious to see where people ignore errors:

       f, _ := os.Open("filename")

"_" is a throw-away variable to indicate that this value won't be used in the code. It's obvious that the programmer decided to ignore the error.

       f, err := os.Open("filename")

If you don't use "err" later, this won't compile.

       f, err := os.Open("filename")
       if err != nil {
          // handle error
       }

This code handles error.

<comment><USER6> This is a bad idea that keeps coming back again and again.

I see nothing wrong with exceptions, I do have a problem with (1) checked exceptions, and (2) catching exceptions prematurely and (3) people not learning how to use "finally" so they do (2) and rethrow.

Languages like Go and Scala roll out various mechanisms that bring us back to the bad old days of C, when we had to check the return/value and or the error code after every function call... if we wanted error handling to work.

The trouble with this approach is that it increases code bulk. For CS class projects, this isn't so bad, but when you're building real systems, the complexity of the error handling can approach or exceed the complexity of the "normal" path and when that happens you're in deep trouble.

Exceptions drastically reduce code bulk by introducing default "abort" behavior, which can itself be aborted at any level of the program and which can invoke cleanup anywhere in between.

Many programmers in many situations would be perfectly happy to catch "failure to open a file" and "failure to open a database connection" and "failure to connect to a network host" with one simple handler that logs the failure and either aborts, retries or ignores.

<comment><USER7> > when we had to check the return/value and or the error code after every > function call... if we wanted error handling to work.

Errors as return values force you to think about every possible error, which is _a good thing_ for code quality. Look at how much rock stable C software we have out there. Software that can be compiled on many different architectures, run in many different environments, and it all just works, even 20 years later.

Writing code with try/catch is much less work. Not because you have to do less typing, but because you simply think less about how errors should be handled.

<comment><USER8> > Look at how much rock stable C software we have out there.

Which would be what exactly. The work of Knuth and djb I'll grant you, but the rest?

<comment><USER9> *BSD kernels, GCC, tar, gzip, ...

<comment><USER8> BSD kernels have had numerous exploits over the years. GCC is a massive hairball. gzip has had exploits (<http://www.kb.cert.org/vuls/id/381508> for one).

Care to try again?

<comment><USER10> Without defending any given piece of software, the job of the exception advocate is not to prove that return values suck, but that using exceptions produces _more stable software_ as fast or faster. This question cannot be resolved by examples/anecdotes alone.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> _> You can't reasonably argue that this:

      try {
        foo = JSON.parse(input)
      } catch (er) {
        return "invalid data"
      }

is more lightweight than:

      foo = JSON.parse(input)
      if (!foo) return "invalid data

_

This is like saying that walking is faster then driving because I can walk 5 meters faster then it takes me to get into a car. Yes, error codes are more compact in a tiny "Hello world" example because it is only showing one function call. Exception handling becomes more compact when you're writing something less trivial and you don't have to repeat the same error handling code after every call.

 _> Try/catch is goto wrapped in pretty braces. There's no way to continue where you left off, once the error is handled. _

Don't throw exceptions if you can handle the error and continue where you left off. Exceptions is for when you can't continue. Think of throwing as a way to roll back transaction, stop whatever you were trying to do, and go back to the last consistent state.

Obviously, exceptions are not perfect. As author correctly notes, they require careful consideration of what's exception and what's part of normal flow. But they were invented for a reason, and I don't see the article offering any alternative solutions to the problems that exceptions are solving now.

<comment><USER12> > Don't throw exceptions if you can handle the error and continue where you > left off. Exceptions is for when you can't continue.

Yes, although quoting that example doesn't support the assertion. JSON.parse is a library function. How can it judge whether the caller can continue or not just because the JSON cannot be parsed?

> Think of throwing as a way to roll back transaction, stop whatever you were > trying to do, and go back to the last consistent state.

Any try block that is larger than one atomic operation can become a nightmare to roll back, since the catch gives you no idea how far it was into the block, what resources were allocated, etc. So although try/catch avoids the hassle of checking state after each operation, you pay for it on errors.

<comment><USER11> > JSON.parse is a library function. How can it judge whether the caller can > continue or not just because the JSON cannot be parsed?

Don't make assumptions about the caller, throw if your library can't continue.

> So although try/catch avoids the hassle of checking state after each > operation, you pay for it on errors.

If your language supports RAII ([http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...](http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization)) you get a free ride. Otherwise you have to write non-trivial cleanup code regardless of how you return errors. _Try/catch_ (and especially _finally_ ) helps a lot because you get to group all your cleanup in one place. With error codes the code looks something like:

      a = acquire(A)
      if (!a) return

      b = acquire(B)
      if (!b) {
         release(a)
         return
      }

      c = acquire(C)
      if (!c) {
         release(a)
         release(b)
         return
      }

      ...

This is a maintenance nightmare. It's hard to see what the code is doing because the real logic is hidden between piles of error handling stuff. If you add a new resource acquisition in the middle you have to go over every statement that follows and modify error handlers. And don't you dare changing the order of statements, because that basically forces you to rewrite the whole function. Believe me, you don't want this in your code, exceptions are your friend :)

<comment><USER13> No, the way to handle that pattern is with nested gotos:

        a = acquire(A);
        if (!a) goto err_a;

        b = acquire(B);
        if (!b) goto err_b;

        c = acquire(C);
        if (!c) goto err_c;

        do_stuff(a,b,c);

      err_c:
        release(b);
      err_b:
        release(a);
      err_a:
        return;

This is precisely why goto is not universally evil.

<comment><USER14> Consider:

      a = acquire(A);
      if (a)
      {
      	b = acquire(B);
      	if (b)
      	{
      		c = acquire(C);
      		if (c)
      		{
      			do_stuff(a,b,c);
      		}
      		release(b);
      	}
      	release(a);
      }
      return;

</comment></comment></comment></comment></comment><comment><USER15> _> I much prefer php's json_decode function, since it just returns `null` on invalid input._

A function which has the same result in case of an error as when given valid input (hint: 'null' is a valid json string) is neither good design, nor something I would actually 'prefer'.

Aside of that (and more to the point of the original article), I do believe that exceptions can be very useful the deeper the abstraction of your libraries gets.

If you are 'far down' the stack and you want to ensure that you are in a position where it's safe to proceed and making it very, very clear for the caller that something went wrong, trow() is the perfect tool in order not to be called with a garbage argument on a successive call to a different function (hint: error results tend to get ignored).

And if you are a user of a library, getting nice exceptions can be very handy too - sometimes even wrapping and re- throwing them.

A very good example of real code: In a command line script which processes a lot of text-data to import into a database delegates to various importer classes depending on import line type.

All these importer classes do their thing and whenever they come across an issue, they just throw an ImporterException _with_ all the context that they know about.

The parent script only has to deal with one single case of Exception to produce nice error messages and show everything about the context where they happened.

I can make the importers as complicated as they need to be and I never have to check a single return value (or forget to check it). There is one central place to handle whatever kind of Error that can creep up.

This is _very_ handy.

Granted, in JS/node where each callback cleans out the stack so that a thrown exception can't be handled by whatever caused the callback to be executed later), exceptions are useless and actually harmful because they can mess up the program flow (which assumes callback to be triggered eventually).

But exceptions being useless in one environment doesn't make the useless everywhere.

<comment><USER16> I thought a JSON document had to have either a top level object or array, which would make a bare null an invalid JSON text. Granted, we might not be that strict all the time.

See section 2, paragraph 2: <http://www.ietf.org/rfc/rfc4627.txt?number=4627>

<comment><USER17> The issue with the JSON spec is that it's deceptively simple. For instance, this particular issue comes up relatively often. As you point out it's quite specific that a valid "JSON text" has a top level object or array. This assumption is even required for the sections on "detecting character encodings" (which makes me wince to this day).

The particular issue is that the spec refers to "JSON text" (which no one ever uses in practice) as well as "JSON value" which is what everyone expects. The difference being that a "JSON value" is any of the 'bare' types (null, boolean, number, string, object, or array). A quick survey of JSON parsers will show you that most will accept any of these types at the top level. The one notable exception I'm aware of is Ruby's JSON library (the default one? I'm not so hip to the Ruby).

Notably, though, is that the major JavaScript interpreters _don't_ enforce this constraint (Nor do Python or YAJL (kinda) or Erlang (even the ones I didn't write)).

Don't bother asking me about invalid combining characters as \u escapes. You wouldn't like me when I get the rage eyes.

</comment></comment></comment><comment><USER18> It looks great on simple examples, but now consider your stacktrace is 5+ levels deep with some generators doing their generalised work on some collection. If the last function fails, then you better be sure that every single level:

\- returns the error message and context instead of just error code

\- wraps the internal problem properly inside its own error description and context

\- cleans up all internal state

Guess what... that's exactly what exceptions do. If don't do the first point, you'll end up with multiple causes producing the same error number. If you don't do the second, you'll get "invalid data" when parsing json (where? what data? which line? which element? why is it invalid?). If you don't do the third, you're going to crash anyway.

So if you don't use exceptions to make your code nicer, you're going to end up implementing the same flow over and over again in places that could just allow the exception to pass through. You might even write some helper/macros functions to... add a file and line number when wrapping previous exception. It feels like reinventing the wheel.

Edit: Forgot to mentioned the collection processing in the end. What is tricky about it is that for a common "map()" to stop on error, you'll need to have a common way of handling errors. Exceptions do this just fine, custom methods - not necessarily.

</comment><comment><USER19> > At least JavaScript doesn't have typed catches. Holy black mother of > darkness, that shit is intolerable.

I would like the author to expand a bit instead. In python there are typed catches, it seems to make a lot of sense to me: you catch only the exceptions you want, and let the other ones bubble up. It is well explained in Martelli's Python in a Nutshell.

I have seen try/catch construct in Java and Javascript, and it is probably less readable, and certainly can be over-used, but in Python, returning None in all exceptional cases is annoying, different issues got merged into a single "Muted" case.

</comment><comment><USER20> Rule #1 of programming articles: Be wary of anyone who states "always" or "never" or "harmful" or "evil" with regards to a code construct/idiom/pattern.

What they're telling you, in effect, is that they know everything there is to know about X, and so you should trust their judgment and not think for yourself.

And in every case I've seen so far (including the famous goto debacle), they have merely focused on their pet code, ignoring the actual cases where the construct is useful (most often, they'll include trivial examples when the construct is meant to be used in complex situations), and this article is no exception.

When your argument becomes "we should throw this out because bad programmers use it badly", you have no argument.

</comment><comment><USER21> I think that having alternatives to try/catch is generally worthwhile. Exceptions should only be thrown in exceptional circumstances.

So (to take some C# code as an example), I'd only call int.parse(myString) if it really, really should only get called when myString contains something that's parseable to an integer.

If it just probably contains an integer, then I'd call int.TryParse(myString, out returnedInt), and check the boolean return to see whether it was valid.

</comment><comment><USER22> This part really sunk in for me in Bruno Jouhier's reply:

> _"So the big mistake I've always seen people make is being too "nervous" > about exceptions and feeling that they have to do something about them as > close as possible to the point where the exceptions were raised. They need > to the exact opposite: feel relaxed about exceptions and let them bubble > up."_

Hadn't really thought about it in that way, but I find myself employing this pattern where possible - having said that, with async callbacks it can be hard to bubble up when you essentially have multiple logical processes occurring.

Haven't found a solution to this in my own codez yet but I feel a little twitch in my eye whenever I have to do:

        try {
            something = JSON.parse ...

because there's no native `JSON.validate` method.

Not complaining though, definitely not worth losing sleep over .. yet.

<comment><USER23> > "So the big mistake I've always seen people make is being too "nervous" > about exceptions and feeling that they have to do something about them as > close as possible to the point where the exceptions were raised. They need > to the exact opposite: feel relaxed about exceptions and let them bubble > up."

While the principle seems to make sense, I find it unusable with GUI like apps. GUI have hundreds of entry point from various events. If I want to catch exceptions far from their raise I need to do it in each one of those event handler, so that they don't bubble through librairies, literally hundreds of times.

Every beautifully written code I've seen has always been CLI programs. Exceptions probably works for server code where you can crash your single process and/or redo it from your original request. GUI and frameworks apps can't really use crash as an acceptable behavior.

<comment><USER24> _> Every beautifully written code I've seen has always been CLI programs._

I might be a fairly novice coder, but I think a good solution for this would be a client/server model. I'm a full-time Linux user and for various reasons, I really like application which have a daemon mode, with the UI built as a client accessing said daemon. Good examples are mpd or deluge.

This way, the actual code can handle handle most, if not all exceptions and errors at the "CLI level" and expose meaningful error codes to the "API" that the UI uses. At least that's how I'm trying to build my first bigger software project (an image viewer).

Again, I'm a fairly inexperienced programmer, so this might be a foolish suggestion, but I try to give much thought to the way I'm building software. Maybe even too much, I'm kinda prone to over-engineering.

</comment></comment></comment><comment><USER25> > At least JavaScript doesn't have typed catches. Holy black mother of > darkness, that shit is intolerable.

Well, if his complaint is about untyped catches, well, I guess they must suck. But if he thinks that typed catches are somehow worse (hint: they're better), he is wrong.

> But still, nothing is as bad as the common "On Error Resume Next" that so > many terrible VB programs start with.

Ok, everyone who always checks the return value of printf() in C, raise your hands. That's what I thought. The semantics of C is that whenever something fails, you just continue from the next line (statement, whatever...) even if the world is burning. Try-catch may suck, but checking for return values sucks more (in languages without pattern-matching), deal with it.

</comment><comment><USER26> Note to everyone: don't confuse 'try-catch sucks' with 'exceptions suck'.

There's no inherent reason an exception-throwing method can't be invoked in a style that gives back a value/exception pair. That limitation is a property of the specific language, not all languages. For example: exceptions could be caught succinctly if method invocations prefixed with 'catch' returned a value|exception tuple (`v, ex = catch ParseInt("test")`).

The primary difference between exceptions and error codes is the default behavior. Error codes default to 'ignore' and exceptions default to 'propagate'. The rest of the differences (requiring acknowledgement, succinctness of handling, availability of stack traces) are more of a coincidence based on the common decisions in languages like Java, Go, C, C++, python, etc.

I think the main downside of existing exception implementations is they discourage programmers from defining useful error cases for functions. It's so easy to propagate or suppress that anything else feels like massive busy work. Simple improvements would be to make wrapping exceptions easy and defining new types easy (throws FileNotFound as forge MissingNetConfigFile).

On the other hand, the main downside of error code implementations is the ease of ignoring. Go has a very good idea in the "x, _ = funcWithIgnoredError" style, but it extends poorly to otherwise-void methods like 'flush stream'.

</comment><comment><USER27> An interesting read. It's always nice to see people stating their unpopular opinions with proper reasoning.

The author's point of view seems to be pretty Javascript/Node.js -centric. I can relate. try/catch and node.js -style asynchronous coding do not work together. However, I'd say that it's the async programming model that is broken, not try/catch.

Writing code in node.js async style is very difficult for humans to do (at least for me), but compilers are excellent in this type of program transformations (continuation passing style). The Haskell and Erlang compilers and runtimes do this automatically. You write regular imperative code but it's executed in an asynchronous manner using co-operative fibers (maybe together with native os threads).

A similar solution is possible with an interpreted language that has some kind of continuations. Every blocking system call could be translated to a co- operative fiber context switch using kqueue/epoll.

What is really baffling to me is that none of the popular interpreted languages (javascript, python, ruby) seem to have decent continuations. I don't know of a reason for not implementing continuations in an interpreter, is there any? Using continuations, one could implement pretty nice async operations and exception handling.

Using return values for error handling is really painful. I've been writing a system call heavy C program, and about 40% to 50% (in LOC) of the code is error handling. In test code coverage, I can reach just over 50% branch coverage as most error conditions don't happen while testing. I don't know of a nice way to make e.g. the network fail at the right time to test my error handling in that case.

C++ is pretty nice when it comes to error handling and exceptions as resources are cleaned up on error. Python's with..as statement or Haskell's Control.Exception.bracket can do the same thing (the latter is just a regular function, not a language builtin). In C, most error handling is required to free some memory you allocated earlier, but even in a garbage collected language you still have system resources you need to free (file handles, sockets, db connections etc).

<comment><USER28> >> However, I'd say that it's the async programming model that is broken, not try/catch.

This is an interesting point of view, however I'm inclined to disagree on the basis that the async model is representative of how things actually happen; the imperative model is not.

In an asynchronous architecture, the developer is concerned with only the current state and the set of all events that may cause a transition from that state. Whether or not an event is the result of an error condition is irrelevant, one simply invokes a different handler.

I used to consider the asynchronous model much harder to program in, that is until I changed my thought process to work in terms of state machines. Then it actually became much simpler to program in this model since, at the handler level, one has no preconception about what should happen next, only what can happen next and how to handle each of those situations.

>> C++ is pretty nice when it comes to error handling and exceptions as resources are cleaned up on error.

There has been many a discussion about the benefits vs. pitfalls of C++ exceptions. I personally am not a fan since the lack of garbage collection means that there are situations that require lots of tedious and error prone boilerplate code just to ensure that all resources are cleaned up.

I have to admit that perhaps the nicest way I have seen of handling failure is in the concept of Monads in Haskell (and other functional languages). The ability to add the context of failure as a possibility in any computation, without requiring that computation to explicitly consider it is extremely elegant. Add to that the safety of always returning a well defined value that is fully type checked by the compiler and I believe you have a recipe for very effective error handling.

<comment><USER29> "This is an interesting point of view, however I'm inclined to disagree on the basis that the async model is representative of how things actually happen; the imperative model is not."

Have you _used_ Erlang or Haskell? I have heard this line of defense a number of times, but always from people who have to answer "no".

The claim is that it's better to let the compiler handle the issues. You're response is basically that since you learned how to more properly run what the compiler does in your head, you've done better. I would submit that's _support_ for the idea that a compiler should be doing the work, not evidence against. What if you could skip the part where you didn't know how, then skip the part where you had to learn better, and then skip the part where you're running this algorithm in your head, and just let the compiler do it for you from day one, and probably better than you can do it even with experience?

(Humans _suck_ at maintaining invariants. It takes years of experience to even be sort of good at it, and you'll still be terrible compared to a compiler.)

While you should know what the compiler is doing to your code, this is hardly any different than manually implementing the C stack on every function call. The fact that it may occasionally let you do something clever doesn't get around the fact that you really shouldn't be thinking about this on every single function call _at all_.

</comment></comment></comment><comment><USER30> Bruno Jouhier's response nails it. It's funny, but for whatever reason I almost always disagree with Isaac's (perfectly reasonable) points of view.

</comment><comment><USER31> The best part about exceptions (unchecked), is that they allow an exception to automatically bubble upward to the level of code that actually should be responsible for taking action, without having to write a ton of boilerplate code all the way down the call chain.

Even better, when stack traces in exception logs are examined, it's easy to see where in the call chain things are going wrong.

During a database transaction for example, something might go wrong 5 method calls deep, and I should roll back the transaction.

If I'm forced to either use checked exceptions or use if statements to check whether there was success at each level, then that's a lot of repeated boilerplate try/catch/rethrow or if(success) code which unchecked exceptions free me up from having to write.

If all I receive at the transaction level is a failure code, then what do I log, other than "something went wrong?!". With exceptions, all the work is done for me. I just log the exception stack trace and I can easily see what needs to be fixed.

Much of the time, exceptions are useful because they are thrown becuase of something you _didn't anticipate_ happening, as opposed to something you had planned for when writing the code. And when that unanticipated thing does happen, there is nothing more beautiful than an automatically generated stack trace telling you exactly what happened.

</comment><comment><USER32> Exceptions vs error codes seems closely related to dynamic vs strong-typing ala Haskell.

If you use error codes exclusively, then it's possible to do much stronger reasoning about all code paths, and you can create a more robust system. It doesn't have the magic of the static analysis that Haskell's type system enables, but there is a certain "purity" in that no function can have an error pass through it in the call stack without being aware of it. This is exactly what you need in systems programming like an OS kernel where every conceivable thing will go wrong and your goal is to handle _everything_ gracefully.

On the other hand, when writing business apps, you not only have the technical concerns of the system, but your program is primarily a big hairy rat's nest of business logic which may never achieve well-definition. In such circumstances, you never get to a point of stability where you can be so pedantic about the technical details because you have your hands full just trying to meet the ever-changing business requirements. Exceptions are a great help here because they allow you to handle new errors with minimal ceremony and function redefinitions. Just like Ruby duck-typing, this means you can refactor faster, but obviously in a dramatically less robust fashion than Haskell. But if you're operating in an environment where a logical failure here or there is acceptable and code has a short half-life, then you'll get better ROI from duck-typed, unit-tested, exception-notifying code than you will from nearly-impossible-to-fail statically-typed code.

A lot of code probably falls into a gray area where it becomes largely a matter of programmer taste.

</comment><comment><USER9> This reminds me of the Qt framework which is C++ but doesn't make any use of exceptions.

Before I worked with Qt, I never thought this was possible without sacrificing the API, but the Qt API is very clean and doesn't seem to suffer from that design decision. So I looked around in the Qt API for some time, trying to learn how they managed to get along without exceptions. And I think I finally got it.

The whole error handling in Qt mostly boils down to providing _sensible null objects_. That is, instead of using NULL pointers (as in C) or generic null objects (as in JavaScript), for all kinds of objects there are specialized null objects which behave sensible to the most possible extent.

</comment><comment><USER33> The core of the post:

      try/catch, which blurs the line between errors
      that are *mistakes* (accessing a property of null,
      calling .write() on a stream after .end(), etc.),
      and those which are expected application-level problems
      (invalid data, file missing, and so on).

Totally agree.

<comment><USER34> In a typed exception system, you just assign different kinds of exceptions to all of those. Java also distinguishes between checked exceptions ("known unknowns") which need to be declared, and runtime exceptions ("unknown unknowns"). Sure, you can still catch all of them in one place, but that's very rarely a good idea.

A non-typed exception system (that doesn't solve the problem with another mechanism) just sounds like a very bad idea. Is Javascript like that?

</comment></comment><comment><USER35> This is the standard in many languages and one that I believe that java got wrong. It was a little rushed with the whole concept of forcing everyone to handle all exceptions concept and building so many exceptions in for silly things like connection failures and parsing errors that reasonably can be expected to happen constantly in the normal runtime of an application.

I follow the rule in almost every language that my app should still be able to run normally if all try catches were remarked out, otherwise I should be handling something better. Exceptions are expensive and don't always back out nicely when they unwind in most languages.

In Objective-C, we play C rules more often then not and almost never use exceptions (except for assertion exceptions). Rather most errors have a ( out NSError __) pointer if they need to pass up errors.

In Python, it's more pythonic to ask for forgiveness than to check before hand so exceptions happen all the time. I'm not sure how I feel about that though but it seems to work well enough.

<comment><USER36> > It was a little rushed with the whole concept of forcing everyone to handle > all exceptions

Just to clarify, Java doesn't force you to handle _all_ exceptions (maybe it did at one point in time?). Exceptions which inherit from RuntimeException are unchecked and you can choose whether to handle them or not. Exceptions which don't inherit from RuntimeException are checked

<comment><USER37> That being said, I'd like to quote these passages from the official Java tutorial:

 _"Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception."_

Anyway... you don't need to neccessarily handle exceptions even if they are checked (in cases where it doesn't make sense that your code handles them). Add a 'throws' clause and let the calling code handle them.

So the poster of the grandparent comment really got it wrong when it comes to Java and exceptions.

<comment><USER36> > you don't need to neccessarily handle exceptions even if they are checked > (in cases where it doesn't make sense that your code handles them). Add a > 'throws' clause and let the calling code handle them.

The problem with this is it affects the signature of _all_ methods in your call hierarchy up to the point where it's handled as you're forced to declare that you throw exceptions. A simple change in one class could quickly become a breaking change involving several classes just because an exception can now occur.

</comment></comment></comment></comment><comment><USER38> ''Try/catch is goto wrapped in pretty braces.''

From this I can infer that lambda is also an anti pattern.

But as good as this straw man post is, yes you can mis-use exceptions, No that doesn't make it an anti pattern.

<comment><USER39> Glad I wasn't the only one thinking of Lambda: The Ultimate GOTO

</comment></comment><comment><USER40> I think the best is a little of both ways. For instance in python:

      x = some_dict['meh']

Will raise if 'meh' doesn't exist. If you believe that 'meh' should be there in your program, it's fine to 'let it raise an exception'.

However, if 'meh' _could_ be there, it's better to use an error style such as:

      x = some_dict.getDefault('meh', 'some-neutral-value')

And continue without raising because there's _no need_ to raise as there's nothing exceptional here.

Ideally, raising an exception should have the meaning "Hey, something is wrong here and I don't know what to do next". And _someone_ in the call hierarchy would handle this and say "Oh, the connection stopped.. that's why it's not working. I'll reconnect and call you again".

And note that this "parent handling" might be way higher than where the problem occurred..

<comment><USER41> You mean collections.defaultdict [http://docs.python.org/library/collections.html#collections....](http://docs.python.org/library/collections.html#collections.defaultdict)

<comment><USER8> No he doesn't. defaultdict provides a default value for ALL missing values. His approach allows him to target one key in particular, and is a very common python idiom.

<comment><USER41> I'm confused - where does that come from?

      >>> x.getDefault(1, 'Que?')

      Traceback (most recent call last):
        File "<pyshell#2>", line 1, in <module>
          x.getDefault(1, 'Que?')
      AttributeError: 'dict' object has no attribute 'getDefault'

<comment><USER8> Because it's actually (somewhat confusingly, called setdefault).

        >>> a = {1:'foo',2:'blah'}
        >>> a.setdefault(1,'default')
        'foo'
        >>> a.setdefault(4,'default')
        'default'
        >>> a
        {1: 'foo', 2: 'blah', 4: 'default'}

This actually updates the underlying datastructure. Very handy when you want to deal with nested structures, since you can do something like:

        matches.setdefault(keyword,[]).append(s)

This will append s to the list in matches[keyword] if it exists, or set matches[keyword] to [] and then append.

</comment></comment></comment></comment></comment><comment><USER42> OT: Was it always like this that the top 170px are just fixed on groups.google.com and thus are somehow wasted from the horizontal space?

[http://www.az2000.de/pics/screenshots/Screen%20Shot%202011-1...](http://www.az2000.de/pics/screenshots/Screen%20Shot%202011-11-14%20at%2012.29.56.png)

<comment><USER43> OMG. That is a horrible UI. It makes Groups totally unusable. Half of my laptop vertical screen is the unscrollable fixed panel with a few big buttons and the search bar. Then 1/4 of the horizontal screen is fixed with the left navigation links. The actual content are crammed on the lower right half of the screen. The bottom arrow of the scrollbar is missing. Please Google, not everyone has 24-inch vertical monitor.

It used to be that Microsoft's website took up lots of fixed upper screen real estate for "branding." Now they have fixed it and is much more usable. Have the Microsoft designers gone to work for Google now?

</comment></comment><comment><USER44> Isaacs is spot-on, and this is one reason why I love Objective-C. NSException is for _programming_ errors, which should be rare. You can use try/catch, but you almost never do. NSError is for expected application-level errors.

<comment><USER45> This is exactly what I came here to say. NSException and NSError combined with the fact that you can send messages to nil objects and just get nil objects back lead to much "cleaner" code in my opinion.

</comment></comment><comment><USER46> I think he has a really interesting POV but the conversation as a whole is definitely a very informative dialog on the value of try/catch in an async environment. As they say, read the whole thing...

</comment><comment><USER47> I think a lot of programmers use try/catch when what they really want is Prolog-style failure:

      my_parser(String, Output) :-

        parseJSON(String, JSON),

        extract_the_values_I_want(JSON, Output).

     if my_parser(String, Output) then

      ...do stuff with Output...

     else

      ...show user "couldn't parse" message...

I've been using Mercury (a strongly typed Prolog) for years now and have never once found the need for exceptions (which Mercury supports) to indicate anything other than catastrophic failure.

<comment><USER48> What are your motivations for using Mercury? Are you using it for hobby projects, research/academic purposes or actual production code?

<comment><USER47> Hobby projects and hobby research. It has some pretty intense features if you're into type theory.

IMO the library support isn't yet there for production code (e.g. no or only rudimental GUI/networking code). But if you're just using it for computation (e.g. AI or compiling or some such) it's pretty solid, and its FFI is the most straightforward I've ever seen.

FWIW I hear that these people: <http://www.missioncriticalit.com/> and these people: <http://www.princexml.com/> use it for production code, but I don't know much about them, beyond that Håkom Wium Lie (of CSS and Opera fame) is the Director of the latter.

I maintain a blog about Mercury's features for interested users: <http://adventuresinmercury.blogspot.com/> if you're interested.

<comment><USER48> I'm definitely interested. Thanks. I've now bookmarked your blog.

</comment></comment></comment></comment><comment><USER49> The way I see it exceptions are helpful in creating self documenting code _if_ used thoughtfully and effectively.*

Some might argue subclassing the base exception to create more specifically named ones is a bit silly, because you may be doing little more than renaming a class several, maybe many, times. But it may be countered that this is simpler than determining a list of error codes and then leaving it to other people to find out what a random string or integer even means. I personally haven't found this helpful for debugging.

Both ways are better than something just returning false and leaving you to figure out why it did that in the first place.

The main benefit to me, however, is to be able to throw the exceptions deeper in the code (where appropriate) and to be able to then catch them at the very last moment. While not perfect (I can't account for everything), it allows me to keep my error handling code cleanly separated from the rest of it at the most abstracted point. Anything lower level will by necessity be a little messier.

 _eg. not wrapping an_ entire* script in one try/catch block.

</comment><comment><USER50> I dont understand this. According to some believe exceptions should be used in an exceptional context. Can anybody define what exceptional is?

I use exception to get the context in which the error happend. Call stack, variables, stuff like that. I can log it, i can give good error message to the user. I never think about if an error is exceptional.

</comment><comment><USER51> > Try/catch is goto wrapped in pretty braces. There's no way to continue where > you left off, once the error is handled.

...

> But still, nothing is as bad as the common "On Error Resume Next" that so > many terrible VB programs start with.

Assuming "On Error Resume Next" does what I think it does, you can't complain about both of these at once.

<comment><USER52> "On Error Resume Next" does _not_ do what you think it does. It ignores the error, and marches blithely on. That is very different than "continuing where you left off, once the error is handled."

<comment><USER53> One of my personal pet peeves is seeing: "try: foo() \ except: pass" in code.

</comment></comment></comment><comment><USER54> I think a good rule is that if you're not planning (or able) to confidently deal with an exception and put the app into a known state, then don't catch it.

Some developers seem to have a fear of allowing any errors to be seen by the user and so they have a habit of swallowing exceptions. I guess it makes them feel that the code is more stable, but it actually masks bugs and makes them impossible to troubleshoot. I have a name for these - I call them "insidious bugs" especially when they result in data loss, which is common with those types of bugs.

I was just in some code the other day that was littered with a bunch of these:

try { ... code here ... } catch(e) {}

not even a console statement or anything! It took two of us over 6 hours chasing down what should have been a 15 minute bug due to that code.

</comment><comment><USER55> The problem with try/catch, really, is that it makes a tremendous amount of visual noise, which makes sense for critical operations that might crash everything, but just don't make sense when you can tolerate certain errors or checking for proper output with with a conditional looks better and is more appropiate.

Obviously then you have an issue with language conventions. How do you check for the returns of a method that does an in-place modification without returning anything? What happens when Null is a proper return value? What about having to access specific members or registers to check?

Perhaps, much like logging frameworks, we may need to categorize throwable actions by their importance, or think of a new convention that can handle such things more easily.

<comment><USER56> But what is your alternative? Doesn't checking the return code of every statement also make a tremendous amount of visual noise?

I've seen C code where about 80% of the code is dedicated to error handling and corner cases. Before every statement it has to check the current error status, and after it the return value... it's almost unreadable.

With try/except/finally a lot of that can be cleaned up, by handling the errors higher-up in the call hierarchy where they make sense to handle.

I see a lot of critique of exceptions, but haven't seen one better alternative yet, at least one that doesn't require switching to an obscure programming language.

Edit: this does assume that exceptions are used properly: for errors that should bubble up, not as extra return value.

</comment></comment><comment><USER57> _try/catch, which blurs the line between errors that are mistakes (accessing a property of null, calling .write() on a stream after .end(), etc.), and those which are expected application-level problems (invalid data, file missing, and so on)._

While I tend not to be a big fan of try/catch myself, one thing I like about Objective C and Cocoa is that they at least provide classes to separate programmer mistakes (NSException, used with try/catch) from application issues (NSError, used however it best fits the app). If the try/catch pattern must be used, I think its sensible to have this kind of separation of responsibilities.

</comment><comment><USER58> How on earth can types catches be worse than untyped catches? As a Pythonista, this whole argument makes my head hurt. He's railing against everything considered beautiful about exception handling in the Python community.

</comment><comment><USER59> "The really nice thing about the cb(error, result) approach is that it constantly reminds the programmer that you _must_ acknowledge that failure may come from any request you make."

</comment><comment><USER60> As we say in C++ "exceptions should be exceptional".

</comment><comment><USER61> Exceptions can make your code much shorter and readable by the virtue of centralized error handling. However, try-catching can be pretty ugly in cases when you need to handle exceptions right away. D language has scope guards to help this. I think we need some kind of better syntax to handle cases like this, but getting rid of exceptions entirely is a bad idea.

</comment><comment><USER62> Try/catch may be an anti-pattern in a dynamically-typed language, but not in a static-typed language. In static languages they're important and valid because they help avoid the "returned a null what?" question.

<comment><USER63> Exceptions aren't the one and only solution to 'null' issues in Java et al.

<http://blog.orbeon.com/2011/04/scalas-optionsomenone.html>

</comment></comment><comment><USER64> Anyone have an opinion with regards to Ada is this context? From what I've read from Ada it tries to do soft errors as a rule.

</comment><comment><USER65> It's only an anti-pattern in languages that don't have resumable conditions (i.e. other than Common Lisp).

</comment><comment><USER66> I'm not sure how I'm supposed to read this... I guess I need an account?

<comment><USER5> Sometimes Google Groups ask for an account, sometimes don't -- not sure why. Anyway, here's the post: <http://pastie.org/2861111></comment></comment>


Why Google Glass Will Crater - <AUTHOR> http://readwrite.com/2013/05/10/why-google-glass-will-crater

<comment><USER2> The author says that Glass doesn't work with prescription glasses. This contradicts what I've read in several other reports. Also, this reads like hastily written first draft.</comment>


Show HN: Saga – Git-style version control for non-text files - <AUTHOR> Hullo HN!
TL;DR: We're adding branching/merging workflows to non-code things. Eventually, we'd like branching/merging for Excel, CAD, movie editing, etc.
We're currently in a heavy use research phase trying to figure out our best entry market (if any) - but ya gotta get something out the door, so here we are.
Any/all feedback on the pre-alpha product or more generally is greatly appreciated!
The website: https://sagalab.org/
The CLI:  https://github.com/saga-vcs/saga <comment><USER2> I guess it offers more specific features compared with git-annex or lfs?

<comment><AUTHOR> Yeah, ideally it'd be a fully featured version control system for other sorts of files.

Aka: git diff, status, merge all would work for these other files!</comment></comment>


Ask HN: Feedback on my product idea please. - <AUTHOR>

Narrated programming. A product which allows programmers to narrate what they are doing as they code.
Why, you ask? Because programming could become a spectator sport. Sound ridiculous? Only a few years ago video gaming as a spectator sport seemed far fetched. Now it's big business. I think people will want to watch other programmers work and understand what they think and how they do it. I would certainly be interested in watching some of the best programmers at work - as long as the narration was effective and meaningful. That's what this product would do - help programmers to narrate and capture meaningful commentary.
Thoughts and feedback? <comment><USER2> Unfortunately I'm pretty sure there are already tools out there that do this.

<comment><AUTHOR> Like what?</comment></comment>


The IE6 nightmare might be back soon - <AUTHOR> http://webjac.com/2013/04/the-ie6-nightmare-might-be-back-soon/ Learn about the browser that is on the way to become the new IE6 <comment><USER2> Sure, let's forget all about the hundreds of millions of IE8 installs.

<comment><USER3> It's completely unclear to me what you mean by this, and what relevance it has to the submitted item. The article is saying that perhaps Safari Mobile is going to have all the undesirable characteristics of IE6, and cause all of the same developer headaches that IE6 caused. It seems a reasonable thing to say, even if people disagree with it and offer alternative points of view.

So I really don't understand what your comment is saying, or what it adds to the discussion. Could you expand on it?

Thanks.

<comment><USER2> Hi Colin!

Mobile Safari gets updated when iOS is. The vast majority of iOS devices run the most recent version of iOS. Therefore, most iOS devices have a current browser and will remain current.

Mobile Safari is not a bad browser, but Android Browser and IE8 are. Hundreds of millions of devices run Android Browser or IE8 and we're stuck with those for a long time to come. So yes, there's a new IE6 nightmare, but its name isn't Mobile Safari.

<comment><USER3> Thank you - that's a much more constructive and helpful reply - now I can see what you mean.

I'm not a web developer, but I like to keep track of the broader picture, and articles like this, with responses like yours, are useful.

Thanks.</comment></comment></comment></comment>


Ask HN: Can below average math guys become better programmers? - <AUTHOR>

So I don't have a good background in math skills. Should I skip trying to learn programming and focus on maybe Sales/Management ? <comment><USER2> You dont need math at all. I learned to program when I was 12. At the time, my math skills topped out at long division.

Then I went to engineering school. I had taken calculus in high school but failed. I failed calculus again in college. Twice (two different courses, once each). Eventually I gutted through it all and learned it, got my degree and went on to an enlightening, but short career in a very math-heavy role - structural dynamics.

Fast forward, and I do web development for a living. Not once* have I done anything in programming that required skills beyond those that I had when I was 12.

So you tell me, am I above average in math skills or not? I haven't a clue.

* I lied. I did build a ballistics calculator once - but that is a very specialized niche of programming. I can assure you there is little to no math in CRUD apps.

</comment><comment><USER3> It also depends on what you're programming. I do iOS apps, which is basically just displaying pictures and grabbing data from the Internet-- no fancy math needed. Though I've been dabbling in OpenGL ES 2.0 recently and the shaders are kicking my ass with math!

</comment><comment><USER4> This isn't a direct answer to your question - but why not work on obtaining a better background in mathematics? I guarantee you it isn't as hard as you think. Until you are at the very highest levels of numerical analysis or meta- mathematics, it's not beyond the cognitive capabilities of the average person - most people just give up and rationalize it by thinking it's beyond them.

Why is your math background so weak, in your opinion? If the answer is that you didn't put in the time, energy, and focus to learn it the first time around, then you have other problems beyond a weak mathematical ability. If it's that you never had good instruction, then it's worth the investment to find it.

<comment><AUTHOR> Recently I started getting interested in math and science after connecting the dots using systems thinking. Several stuff in math is interrelated to different pieces within it. I didn't knew that at the time when I was in school. Yea I can become better at math, but I'm not sure if I should just focus on my strengths or improve my weakness i.e maths which can take alot of time. Maybe I can focus on things which will have big impact in my life ?

Yea I didn't had good instructure. I also changed alot of school during childhood, that may had changed curriculum alot of times and my basic math skills were messed up. Here in India they don't teach you much. Students here are more interested in getting that piece of certificate(graduation degree) and showing it to the employer rather than thinking about what to do with the knowledge they have. Sometimes they don't even have knowledge cuz they just do rote learning without connecting the dots or understanding the concepts.

I downloaded couple of ttc lectures, and they explain these stuff in a awesome way.

</comment></comment><comment><USER5> Mathematicians tend to be good at solving puzzles. "Read the problem; state the problem; state what you know and what you need to know; think about how you find what you need to know and how to get there.".

That's pretty handy skill for programming.

Some people think that programming is an inherent skill - [http://www.codinghorror.com/blog/2006/07/separating- programm...](http://www.codinghorror.com/blog/2006/07/separating-programming- sheep-from-non-programming-goats.html)

Other people suggest that you just need to do it. (All those "Learn X the hard way".)

I'd be interested to know what the research says.

</comment><comment><USER6> I find if you're good at applying logic you'll do just fine programming. Math really helps when trying to prove why good logic is right. Plus most math used in CS is just powers of two and basic algebra... nothing fancy.

</comment><comment><USER7> The kind of math you need for programming (except in games, analysis, or other specialized subsets of programming) isn't trig/calc/etc. It's just simple logic, and except in that rare instance once you start speaking the language you don't even think about the fact that what you're writing are mathematical statements, it just comes naturally.

A lot of people get confused about the math requirement for programming. You don't need to know what 356^84 is, you just need to know how to tell the computer to calculate 356^84.

It's surprisingly easy once you get started.

<comment><USER8> I strongly agree with this. Remember that being a good developer has as much to do with creativity and in some respects artistry as it does with algorithms (see PG's essay Hackers and Painters <http://www.paulgraham.com/hp.html>). The tone of this question is a bit concerning though. Why are you currently a programmer (if that is the case)? Do you enjoy building things by writing software? Do you want to solve more advanced technical problems that might require higher level Math? Or are you considering a different path because you are tepid about programming? This career, in my estimation, is something you need to have passion for. So make sure whatever you decide that part is true.

</comment></comment><comment><USER9> Depending on what you want to program, lack of math knowledge might mean you'll have to dig a little deeper into some subjects at first and gain that missing knowledge. But that's it. Just some extra time. Go for it :)

</comment><comment><AUTHOR> Well I'm specially not good at calculus, geometry, probability etc. I can do algebra and statistics after some practice.

</comment><comment><USER10> You'll be fine.

<comment><USER11> *As long as you aren't hoping for a university degree. Saw many, many, many below-maths students not able to complete a CS Degree and some not even Software Eng. because of a lack of Mathematics skills.

However, you're ability to conceptualize, use, alter, convert, code, write modules, etc won't be effected as long as you put in the necessary effort.

<comment><USER12> Seconding this. In senior year of university, the math requirements of the CS track went from second-grade arithmetic to being expected to have finished your math minor. It was quite the jarring shift.

If you want to program, you don't need to know much in the way of mathematics. If you want to program well, knowing advanced math will open up new possibilities for problem solving. If you want a CS degree, start taking math courses now.</comment></comment></comment>


Book Review: Gusher of Lies by Robert Bryce - <AUTHOR> http://www.nytimes.com/2008/03/07/books/07book.html?ex=1362546000&en=8185e8b543ec71be&ei=5090&partner=rssuserland&emc=rss&pagewanted=all

<comment> daniel-cussen _This article has been revised to reflect the following correction:

Correction: March 11, 2008 The Books of The Times review in Weekend on Friday, about "Gusher of Lies: The Dangerous Delusions of 'Energy Independence,' " misstated the author's surname at several points, and a description of an online excerpt from the book misstated his surname as well. As the review noted elsewhere, he is Robert Bryce, not Bruce or Boyce. The bibliographical capsule with the review misidentified the publisher. It is PublicAffairs, not Basic Books._

</comment><comment><USER2> I was hoping to see the book review here.</comment>


Silicon Valley Loves Alex Karp and Elon Musk - Piazza Recruiting Data - <AUTHOR> https://recruiting.piazza.com/insights

<comment><USER2> Would be interesting to see more analysis of what these numbers mean. Is it salary? Benefits? Work environment? Interesting work? (Big companies do not offer the most interesting work, in my experience.) Long-term stock upside? Or just ... brand?

[Edit: I mean why do students choose the way they do?]

<comment><USER3> I'm currently a student. I think it's easy to get us to drink the Kool-Aid about how much nicer life is at one of those big companies.

Myself included, it is easy to forget you have a lot of work to do at these places. I've heard these places described as "adult Disney land ", "just, better than the east coast " and "way better than Google " by recruiters.

<comment><USER4> Great insights @theboss</comment></comment></comment>


Novim-mode: Use Vim like a 'conventional' editor - <AUTHOR> https://github.com/tombh/novim-mode <comment><AUTHOR> From the README:

 _Some, indeed many, may say this is counter-productive or even sacrilegious. But Vim is a lot more than just a keybinding paradigm; firstly it has one of the richest plugin ecosystems of any editor, but also it is a --if not the most-- ubiquitous text editor that 's been battle tested for over 25 years. There are more reasons to use it than merely its famous shortcut vocabulary.

This plugin is an attempt to expose everything else about Vim without the overhead of cultivating Normal Mode fluency. This is not a rebellion, it is merely a manifestation of the distinction between Vim the editor and Vim the keybinding paradigm. Please do not dismiss Normal Mode just because this plugin exists, give vimtutor a try, modal editing is popular for a reason.

Vim itself already has support for something similar in its optional mswin.vim config file. However it still assumes the necessity of Normal Mode and such heritage as SHIFT+INSERT-style combinations. This plugin however, attempts to avoid Normal Mode unless absolutely necessary, say for interacting with the NERDTree buffer, wherein Insert Mode has no purpose.

The name novim-mode is a nod to the prevalence of 'vim-mode' plugins and extensions available in environments outside the editor, such as web browsers. In the same way that the love of Vim has led to efforts to export it elsewhere, 'novim-mode' is the love of 'conventional' editing imported into Vim._</comment>


Apple Fails at Customer Service - <AUTHOR> http://garmhold.blogspot.com/2009/11/apple-fails-at-customer-service.html

<comment><USER4> DOA probably isn't the right term here. Neither machine was DOA. Anyway the point of advance replace is a good one. Apple also doesn't have on-site service which is a major issue for big heavy computers that are typically used as professional workstations. Apple, as a company, seems rather clueless about enterprise level support. They're missing out on a small but insanely profitable part of the market. People will pay a premium for the best support possible. This goes for computers and software developers. How many iPhone developers would pay a few thousand dollars a year to get A list treatment? (a lot I think)

<comment><USER5> Apple applies the same principles to customer service that they do to their products.

Rather than tier service -- and by design treat some people badly and some people amazingly -- like many companies do, they work hard to find a good middle ground where everyone is sufficiently happy and receives almost the same level of service. Necessarily, this means some people used to amazing support will get worse support and those used to shitty support get better support.

Whether you like it or not, it seems very strange to me that someone would say Apple is "clueless about enterprise level support." Of course Apple understands how the industry standard is for enterprise support. They most likely consciously do not copy it.

<comment><USER6> Enterprise support is what you need when you're selling $3,500 towers because that's the where most of the sales come from. Not many consumers drop that on a PC.

<comment><USER5> And an Apple MP3 player must have an FM radio built-in because all the other companies put them in their players.

<comment><USER6> I don't see the connection. Not all statements about Apple are wrong because one is. Apple sells about as many desktops to enterprise in a year as the average Best Buy and this is probably part of why.

<comment><USER5> My point is that most companies, like Dell, sell their consumer machines at a horrendously low profit margin. They make it up in enterprise sales.

Apple, however, sells consumer machines at a tremendous profit. The value you think Apple should see in enterprise is negated by their own business model being different from the industry norms.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is truly the one amazing thing Dell has over Apple.

One of the fan filters on my Dell laptop got clogged, which caused the graphics chip to overheat (resulting in slow graphics performance and blasting fans). I called Dell in the afternoon on a Monday and did 15 minutes of troubleshooting. They said it might be a problem with the model of graphics card or motherboard.

The next morning there's a Dell tech taking my machine apart, fixing it, and walking out in 20 minutes. Total disruption to my work was less than an hour that week.

Another time I was traveling (for work) in another country and I broke my laptop (dropped it). Dell had a contractor in my office with replacement parts the next day. I didn't have coverage on it though, so that time cost me a few hundred. I'd probably have been SOL with Apple though.

<comment><USER8> Yeah, Dell are great at support. </sarcasm>

My Dad's PC had a DVD-ROM drive that died. I was on the phone to Dell support for A WHOLE DAY. THe problem was trivial, but I got shunted around, told to try all the crappy shovelware shit they'd put on the PC that I'd uninstalled, etc.

XP's built-in CD burning just plain failed to work. Dell support tried to tell me that the CD-ROM drive was not compatible with XP's CD burning (totally nonsense). I even had to give them my credit card number to sign up for their software support (as well as the cash I'd paid for next-day hardware support), because "it might be a software problem, so you have to pay for software support." At least they had the decency to refund that.

They'd established (or rather, I had) that the drive was faulty, so they wanted to mail me a drive and I could fit it. As I'd paid for next-day on-site warranty I told them they could take a running jump.

Next day, hardware guy turns up, replaces drive in about 10 minutes, fixing the problem.

A WHOLE DAY on the phone. I've never bought Dell support again.

<comment><USER9> Consumer level support is completely different than enterprise support. --Generally with enterprise support, companies like Dell assume someone competent has already done initial troubleshooting. It's cheaper for them to pay people to spend the day on phone rather than sending someone onsite for something that might not actually be a hardware issue.

I'm not saying it's right, that's just the way it works, unfortunately.

</comment></comment></comment><comment><USER10> This might add some light on the phone calls from higher up the chain - <USER2> also has the advice that this month is the time to contact Apple Support. <http://www.cringely.com/2009/12/ask-and-ye-shall-receive/>

(The gist of Cringely's post is that Apple want to top the JD Power listings for quality and support. This means that this month apple will bend over backwards to ensure they're keeping people happy)

</comment><comment><USER11> I also had a serious issue with my new MacBook Pro I purchased for business use.

Upon arrival, it constantly froze for between 2 to 30 seconds during any kind of task. Extremely frustrating and disruptive to productivity. I took it back to the Apple Store, and they told me they needed to swap the hard disk.

Fine. Time Cost : Trip during business hours to the Apple store, and perhaps 2 hours waiting around. 1-2 days without PC. Backup/restoration of all backup data.

After this, I went to the Apple store and got the computer back, and took it back to the office. It was exactly the same as it was before - <USER3> freezing.

I took it back again. This time, they said it must be the logic board. I argued this - a lot of other people on the Apple forums are also complaining, and they say it's due to incompatibilities by having shock detection systems on both the hard disk and the MacBook Pro itself.

In the end, Apple said fine, let us take the PC and run tests on it. Within 1 or 2 days, we'll know what the problem is, and we'll be able to fix it.

Well, I asked, how long will it take you to fix it after you figure out exactly what the problem is?

About a week, they replied.

This is when I started to get a bit upset. This machine I bought for business is not capable of performing the simplest of tasks, and they want 8-10 days to fix it?

Further, it has a serious work preventing problem, and Apple causally asks for a full week diagnosing and fixing this laptop, which I need to use daily for business tasks.

I complained, and eventually got them to simply replace pretty much everything in the PC (HDD again, logic board, memory).

They then said "Alright, because you have a built-to-order machine, we don't have the parts here. We'll need to send it out, and it'll take about 5 days."

Upsetting. I naturally complained again.

"You should get the business pack. It only costs 20,000 yen (or something along these lines), and you get priority service for a year. You'll get your laptop back in 1 day. All the businesses have this."

Once again, upsetting. To have wasted days of my time trying to get Apple to fix it, and then to be hit with a surcharge for them to fix a problem in a reasonable time frame that is likely THEIR fault in the first place!!

I complained, spoke to a manager, and had this fee waived, and they promised to return it within a day. Finally, this was a satisfying solution.

I submitted my laptop, had it back the next day, and still had freezes, but they weren't as bad. I almost went off Apple forever, but then a few weeks later they introduced some firmware changes that cleared up my problem.

Now I am very happy with my laptop, and I believe it's the best machine I've ever used.

However, I couldn't help but compare my experiences with "AppleCare" and how they support their flagship business laptop, to any experience I've had with the most basic PC configurations from Dell.

Dell will come on-site almost immediately, fix things quickly and efficiently, quickly ship replacements of broken equipment or broken PCs/Laptops.

It's a dream to get support from Dell.

But look out if you have an Apple machine you plan to use for business.

</comment><comment><USER12> I've only experienced issues once with a local store, and a call to Apple's Customer Hotline (or whatever it's called) fixed that real quick. I was in a situation similar to yours (starting a new job, _had_ to have the machine), and I was told I had to wait for them to repair it. After a number of back and forth conversations over a day or so and the manager ignoring me for a second time when I tried to appeal in person, I called the hotline.

The store called 2 hours later to tell me to pick up a new, updated machine, ready to use with my data transferred over (keep in mind the issue I took the original machine in for was super minor).

I know it's anecdotal, but every time I've had to interface with Apple people, it's been nothing but pleasant (even with the App Store).

</comment><comment><USER13> I think the tech support you had could have been a lot better and I will say that such issues usually pop up for me with dell. Dell does 1 thing right and that is NBD On-Site Warranty.

Also, I don't understand why you had an issue with advance shipping of you Mac.

I bought a macbook pro which was DOA this summer and was in a similar issue where I had just started the job and needed the laptop. I explained this to them and they faxed me a contract which specified that they will send me a replacement and I had return the original within 30 day. They took down my credit card details but I confirmed it with them that my card will only be charged if the laptop is not returned within the 30 day period. I just needed to print that paper, sign it and fax/scan and email it to them which I did. I spoke to Apple on the Monday, got the contract taken care of on Tuesday and had the computer by Wednesday morning.

Also, note that that Monday was WWDC and they managed to solve all this DURING the launch of a the macbook pros and more.

Do send me an email if you want me to send you a copy of the contract(Advance Replacement).

<comment><AUTHOR> Hey ajaimk, I'd love to get a copy of the contract (with personal details redacted, of course). Could you send it to me at email@example.com ?

Thanks.

</comment></comment><comment><USER14> I've had much, much better service by having my computers repaired by the local indie Mac shop. They generally were a lot more responsive and friendly, and they did the repairs on-site and billed it back to Apple.

Plus I didn't have to make an "appointment" to lug a G5 or Mac Pro all the way through a shopping mall.

</comment><comment><USER9> I can't say I'm all that surprised... I had to argue with one of their "geniuses" about an issue with my Air. He tried to get me to reinstall the OS to fix a failing drive (S.M.A.R.T. was even reporting that the drive was failing).

Took them a week to replace the drive. It probably would have been less hassle for me to just buy a new drive and replace it myself.

</comment><comment><USER15> I see the point about having an enterprise level of support.

I also see two edge cases.

I've had an LCD screen replaced (fo' free) 2 years outside the warranty period —

My first Mac, so it made an impression.

So all you had to do was wait for a postage-paid box and send it back?

As an aside, Apple's Bluetooth mice have always seemed terrible, IMHO.

</comment><comment><USER16> _What's the point of buying AppleCare?_

Like any other extended warranty, the point is to make a nice profit for them and give a warn and fuzzy to people who are not strong on math.

</comment><comment><USER7> If it was me, I'd have:

#1 Used software to manually control fan speed (watching temp).

#2 Bought a $10 USB Bluetooth device.

I hate shipping/going to stores for support.

<comment><USER17> If it was me, I had assemble my own machine. But neither my story, nor yours is related to apple support.

</comment></comment><comment><USER18> "For some reason the fans just started going full-tilt all the time"

Sounds like a kernel panic to me. My brand-new iMac did that on its first day right out of the box ... nothing on it but system software. First, and only, time - go figure.

<http://en.wikipedia.org/wiki/Kernel_panic>

The Mac fans are (apparently) under software control, and a number of testing routines also rev up the fans. It can be unnerving when you first hear it.

<comment><AUTHOR> No, a Kernel Panic would result in a crash. All modern computer fans are under software (BIOS/firmware) control. I also tried re-installing the OS to no good effect. The machine was totally functional, except for the fact that it was miserable to be in the same room with because of the noise.

<comment><USER18> That's ... okay, whatever you want to call it, that's what it was called in the past when there was a problem. (I don't see why I'm getting downmodded for trying to help...)

See this page for many more examples (hope it helps): [http://www.macintouch.com/readerreports/powermacg5/topic2215...](http://www.macintouch.com/readerreports/powermacg5/topic2215.html)

Here's more recent one: <http://discussions.apple.com/message.jspa?messageID=10364393></comment></comment></comment>


Has anyone tried the Fossil SCM? What's your opinion? - <AUTHOR> https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki <comment><USER2> The designer of Fossil and SQLite here...

Git was designed to support Linux development. Fossil was designed to support SQLite development. Those projects have very different needs. The details are the subject of a 1-hour talk and are more than can be compressed into a HN comment. Sufficient it to say that (I believe) there is room in the world for more than one VCS.

Earlier today, a support customer needed to know all SQLite check-ins between versions 3.8.7 and 220.127.116.11 that touched any of the files src/pager.c, src/os_unix.c, or src/wal.c. The answer is on this link: [https://www.sqlite.org/src/timeline?from=version-3.8.7&to=ve...](https://www.sqlite.org/src/timeline?from=version-3.8.7&to=version-18.104.22.168&chng=src/pager.c,src/os_unix.c,src/wal.c)

Is a query like that even possible with Git or GitHub?

In fairness, I had to enhance Fossil slightly in order to support the query above. But the enhancement was minor and only took a few minutes. See the diff at [https://www.fossil- scm.org/fossil/info/b2b62b8318700f9f](https://www.fossil- scm.org/fossil/info/b2b62b8318700f9f)

<comment><USER3> Do you have a link to a video of the 1-hour talk you mentioned?

</comment></comment><comment><USER4> It's nice and works well enough.

However, I eventually switched to git, so that I may easily push to various remote publish repositories such as gitlab and github.

It's a nice feature to have everything integrated into fossil (issue tracking, wiki, etc). However, it is also a drawback or waste when you actually want or need to integrate with existing infrastructure and diverse services providing those features.

The world has standardized on git, and there's a whole ecosystem of tools and services developed around git. So unless you have a very specific and strong reason not to use git, it's hard to make a case for any other DVCS.</comment>


It's complicated: Facebook's terrible 2018 - sahin-boydas https://www.theguardian.com/technology/ng-interactive/2018/dec/24/facebook-2018-timeline-year-in-review-privacy-scandals <comment><AUTHOR> Does anyone have any good devil's advocate information on Facebook?

\- The company does not seem to have an appropriate ethics board (for the size of company). There is some mention of an 'ethics AI board' but no real governance over Ethical conduct and compliance. If there are internal review boards ([https://www.theguardian.com/technology/2016/jun/17/facebook-...](https://www.theguardian.com/technology/2016/jun/17/facebook- ethics-but-is-it-ethical)), then it appears that they are thoroughly compromised, and not providing a level of accountability or serious thought that anyone will take seriously.

\- There seems to be no intention or effort in achieving ISO standards (apart from a single ISO:27001 certification for FB Workplace, which was arguably to provide a 'feature' for the application rather than any ethical move). Granted, the value of standards and frameworks will always be in dispute, but these exist for a reason and are a neat 'package' that organizations use to ensure they are not reinventing the wheel and acknowledging a list of considerations.

\- Facebook do not seem to maintain an ethics page.

\- They do not seem to have an ethical voice - Nor do they appear to have anyone even pretending to have an ethical voice. PR from facebook (usually) manifests as 'We do what we do, and it's fine' rather than 'we will be introspective about this'. It seems strange that there isn't even any posturing here.

\- The two types of FB employee that seem to voice insight on public forums are either a) discontent and being ignored by management or b) drinking the koolaid and refusing to admit that their practice is unethical.

Ignoring Occam's razor for a moment - Surely there is something to cling on to here, to provide the principle of charity for Facebook. FB sure are making it hard for consumers to paint them in any reasonable light.</comment>


John McAfee Wanted for Murder - <AUTHOR> http://www.gizmodo.com/5959812/john-mcafee-wanted-for-murder

<comment><USER2> McAfee Total Destruction 2013</comment>


Black families pay significantly higher property taxes than white families - <AUTHOR> https://www.washingtonpost.com/business/2020/07/02/black-property-tax/ <comment><USER2> My hunch is that the assessors are coming up with their numbers based on the quality of the property and are fair in that regard, but when it comes time to sell the property there is some preference among buyers (call it racism if you will) not to live in a black neighborhood. The assessors in that case should use historical sales data to adjust down the valuation of the property. But could that end up hurting black homeowners in the long run? It's hard to say.

<comment><USER3> "there is some preference among buyers (call it racism if you will) not to live in a black neighborhood"

I will. That is racism.

<comment><USER4> Is it? On the other side of things, might black people want to avoid majority white neighborhoods where the white police will more likely target them as well? Might black people prefer black neighborhood themselves so that they can live amongst people they understand with a culture they're familiar with? Are those black people racist?

<comment><USER5> Probably. But it depends how you define the word. Discrimination based on skin color? Then yes.

<comment><USER4> Freedom of association is important for all people, I believe. If Asian people have been victimized by other groups in American society, they should be allowed to congregate and live with each other, where they will be able to have the power and influence to protect their people and interests. If black people cannot trust the white police force to not kill them, they should be allowed to move to black cities with black police who will less likely kill them. And if whites feel that they cannot live amongst blacks due to their poor relations with eachother, who are we to stop them from leaving? Because forcing two opposing groups to live with each other only breeds more violence and suffering. I wouldn't shame them or call them racist. It's pragamatism at worst. You could bring up statistics all you want to say why x or y is not the case. But that doesn't matter to individuals. People decide these things on their own, in their best interest, for their family's safety.

<comment><USER5> I don't disagree. No free person should be compelled to live or not live in a specific area.

</comment></comment></comment></comment></comment></comment><comment><USER6> Note that California was excluded due to prop 13 heavily weakening reassessments. I generally dislike the law (favors old homeowners over new), but I had never considered until reading this article that removing power from property assessors could itself lead to more socially just outcomes on different metrics.

<comment><USER7> There are some major issues with prop 13 in that it allows people to set up a paper company to own a piece of property, then sell the paper company rather than the property in order to avoid tax reassessment.

<comment><USER8> The loophole is that properties owned by corporations are not reassessed when the corporations are sold

There is already a measure on the ballot to reform prop 13 [https://www.sfchronicle.com/politics/article/California- meas...](https://www.sfchronicle.com/politics/article/California-measure-to- reform-Proposition-13-15304408.php)

</comment></comment></comment><comment><USER9> Seems like the article starts with the conclusion that the disparity is explicitly racially motivate, and works backward.

Why not work from a premise that the outcome is disparate but the reasons might be more nuanced? (that was rhetorical. I know why they didn't) What about:

\- Assessors don't properly account for disparate crime levels for properties that are similar on paper?

\- Minorities are priced out of gentrifying neighborhoods because of rapid price increases. This is why Prop 13 happened in CA in the first place, so middle class folk wouldn't be taxed out of their homes when they exploded in value.

\- Minorities don't know they can appeal their assessment. Who's responsibility is it to know that? Is there evidence that a state actively attempts to hide this info?

\- If they control for race, would the numbers show that white people who live in similarly high crime areas also pay disproportionate property tax? Could it be that black and Hispanic people disproportionately live in higher crime areas, and it is the lack of including crime rates in neighborhoods when assessing taxes is a primary driver if this effect?

</comment><comment><USER10> I thought this was really the crux of the whole thing: " While the analysis is not designed to show "active" discrimination, it cannot be ruled out, Howard said. But, he said, "you can equally tell the story that assessors don't realize how unequally the burden is landing along racial and ethnic lines."</comment>


Writing an API at the Edge with Workers and Cloud Firestore - <AUTHOR> https://blog.cloudflare.com/api-at-the-edge-workers-and-firestore/ <comment><USER2> It seems to me that the benefit of Workers is that they run geographically near the user. If the Worker is calling a database that may or not be close to your user, what is the point? You are going to pay the latency cost either from the user to the Worker or the Worker to the DB.

I realize that there are some advantages. The network between the Worker and a Google datacenter is probably much faster than the network from the user to the Worker. Also, Firestore in particular can be geographically replicated so that the database is closer to your user. But I'm not convinced that these benefits outweigh a more traditional (and more flexible) architecture.

<comment><USER3> The more work you can offload to an edge node, the better-- this is a pretty safe general rule to make.

Think of all of the random conditionals that your http routes have; "is the client posting a correct data structure" or "is this a valid OAuth token" or "am I requesting something that I already have cached" or rate limiting or the list goes on and on.

All of that kind of stateless route level logic that may not need to hit a data store is a perfect candidate for an edge worker, because once you have that deployed, you can concentrate more on business logic within your main application.

For example: "I have a valid OAuth token, I have established my identity, now issue an S3 pre-sign request and forward the resulting URL to the browser to download a protected file". Doing that within a worker will absolutely speed up your user experience by a couple hundred milliseconds at least.

<comment><USER4> Full disclosure - I work on Workers at Cloudflare, so obviously biased :)

There are a lot of performance advantages along every step of the way, as you mention. I think you can look at this from many different lenses beyond performance.

A big advantage was how fast and easy this was to get up and running. Simplicity is key here - it's a simple API written in JavaScript (no config, VPS, etc necessary).

The other really important thing is scalability - when workers.dev went live, we didn't have to worry about being able to handle the spiky workload (preregistration sites end up failing quite frequently). This scales infinitely.

<comment><USER3> Yeah, agree-- the moment that you all get KV to mature to a more Dynamo-like experience with queries and secondary indexes, that opens up a whole ton of possibilities in terms of easily rolling out entire applications that can scale from zero to whatever size.

</comment></comment></comment></comment><comment><USER5> I can't wait to try out Workers. I've always found "serverless" interesting in concept but the cold starts and vague pricing keep me away. It's pretty cool that Workers actually makes latency better rather than neutral/worse.</comment>


Teacher Loses Job Due to Lack of "Trigger Warnings" in Comics Course - <AUTHOR> http://www.bleedingcool.com/2015/10/05/teacher-loses-job-due-to-lack-of-trigger-warnings-in-comics-course-bill-sienkiewicz-raises-the-alarm/ <comment><USER2> > This mentor, this artist , this friend– this TEACHER- lost their job because > the school must investigate every "charge" of trigger-warning and offense > [sic], and immediate suspension results while it's being "reviewed"

Which tells us little. What caused the transition from suspension to losing the job? What was the policy? That is, was it subsumed as part of a sexual harassment policy, or was it singling out trigger warnings?

What kind of school was it - elementary? college? I looked, but found no evidence of a college which requires trigger warnings, other than a short- lived policy at Oberlin.

Finally, note that the original title ends in a "?", while the HN title does not, making the HN title sound more definite than given in the original. Plus, the source material says:

> More info soon, information gathering is ongoing, and the CBLDF is > investigating. I don't mean to be coy with the particulars of who or what > because, Facts.

> However I won't let that dissuade me from using this space as a forum to go > ballistic about this anti-vaxxer analogue aimed at creators.

In other words, there aren't any definite facts, and this link is mostly a second-hand forwarding of someone's rant, along with a 'stay tuned.'

</comment><comment><USER3> There is absolutely zero information in this article. It is some unnamed teacher got fired for SOMETHING from SOMEWHERE and then a long rant about political correctness, trigger warnings, and so on.

To be honest the teacher could be fictional for all we're told here. Nothing even worth discussing unless people just want to use it to rant about political correctness "gone mad" or similar.

I'm actually going to flag this for being of such low quality (and I rarely flag anything).

</comment><comment><USER4> The article presents some good information about how out of control "trigger warnings" have become. And it's interesting that there is discrimination in the things that people are supposed to give "trigger warnings" for. To make things equal here are some more "trigger warnings" that should be implemented in society: -Before stepping into a cafeteria: Trigger warning to vegetarians: There is meat sold here and it might bother you. -On bridges and high places: Trigger warning: Heights present, be careful if you have a fear of heights. -Children's playground: Trigger warning: If you've had a miscarriage or have trouble conceiving this might make you sad.</comment>


The Value of Postmortems - <AUTHOR> http://americastestkitchen.github.io/culture/engineering/2015/05/13/the-value-of-postmortems/

<comment><USER2> I remember staying up until 5AM to do a deploy with you guys, ended up staying up pretty much all night waiting for the DNS to propagate, fun times. Lol.

</comment><comment><USER2> Also my fish shell history is pretty much my best friend in these situations.

<comment><AUTHOR> I do not disagree about the shell history being very important. Some histories do end up getting truncated at a set interval. That was the main reason I brought up tracking this command trail at some point close to the task being completed.</comment></comment>


Schedule Tasks Easily with Iron.io and StackMob - <AUTHOR> https://blog.stackmob.com/2012/12/schedule-tasks-easily-with-iron-io-and-stackmob/

<comment><USER2> I wasn't aware of StackMob. They seem to be a bit like Parse but with no API limits on the free tier (Parse's are pretty high) and better Core Data integration but a less rich API for doing things like saveEventually (which I find useful for logging as it should write eventually when network connectivity is restored even if it is the next run of the app).

I'm going to be implementing my own synchronisation code to allow multiple users/devices to edit a document at the same time and I'm not sure either of these platforms (Parse/Stackmob) are really suitable for that and I've read bad things about UIManagedDocument (iCloud with Core Data) and I want to be able to share between users too.

Does anyone know any good tutorials for handling these things well on any of these services or rolling my own server?

<comment><USER3> I haven't run across or know of any tutorials on this exact problem, but I think you're right that you'll end up doing a lot of the synchronization yourself.

You might check out PubNub and other messaging services. PubNub is a stackmob partner product that can be added in their marketplace. That would provide for a component to handle transporting messages and state information between your document editors.

</comment></comment><comment><USER3> Seems decently useful.

Pretty cool that they can do asynchronous jobs in node, php, go, java, .net, python, and ruby</comment>


101 Ways To Know Your Software Project Is Doomed - <AUTHOR> http://codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/

<comment><USER2> 102\. What's continuous integration? 103\. What are tests? 104\. The Project manager denies the existence of big-O. 105\. The project manager "Know's what he's doing" and rejects CI. 106\. What's wrong with doing it by hand?</comment>