Hacker News new | past | comments | ask | show | jobs | submit login

> "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.




>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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: