Contents tagged with exceptions
-
A harsh reminder that you can't forget what's below the abstraction
So you're a high-level programmer that much that you write software in Flash. Running in JavaScript. In a browser that runs on a virtual machine that runs on an actual OS that... Or simply you write a module that runs in a framework running on a framework running on a framework running on a framework (Orchard - ASP.NET MVC - ASP.NET - .NET) that uses an abstraction of database tables (records) aided by a layer that abstracts a layer that abstracts a data storage (Content Query - NHibernate - SQL) - that BTW itself abstracts a whole lot of things - to wrap it up quickly. And you thought you don't have to think about all that below! Got ya!
I've created a content part that had an innocent little property called Index (what, for the historical accuracy, was of type int), and below that there was a similarly named property in the part record. Guess what I got when I tried to use this?
-
Orchard Gems: Exception fatality check
Catching exceptions with the type of the base Exception class is bad practice. "Never catch an exception you can't handle" says the proverb we all know from kindergarten. But what if we get our dependencies injected by requesting objects by their interface types?