Thank you to all who attended my jQuery presentation this weekend. I had a great time and hope you did too. As promised, I posted my presentation and code samples. It’s hosted on github and you can access it here.
If you have any questions about the content please ping me.
Thank you to all who attended my presentation last night. I had a great time and hope you did too. As promised, I posted my presentation and coding samples. It’s hosted on github and you can access it here.
I also want to thank all of you who provided feedback. This is invaluable and I love reading them. Especially when they provide honest critiques. If you have any questions about the content, please ping me.
In my last post I discussed how exceptions should be treated as exceptional and not used to control work flow. Now lets take a look at how we can manage exceptions to provide a positive user experience without sacrificing the intent of the code.
To start lets review the general guidelines to exception management:
With these simple rules how could we clean up our existing code?
public class Service
{
public IEnumerable<Entity> GetEntities()
{
try
{
var entities = repository.GetEntities("select * from table …");
return entities;
}
catch (Exception e)
{
Logger.Log(e);
return new Entity[0];
}
}
}
To start we can catch an explicit exception, for example SqlException. We could then wrap the exception with a custom type and provide the specific SQL statement that caused the error. finally we can throw the new exception allowing the exception to bubble up the call stack. it would look something like this
public class Service
{
public IEnumerable<Entity> GetEntities()
{
string sql = "select * from table …";
try
{
var entities = repository.GetEntities(sql);
return entities;
}
catch (SqlException e)
{
var wrapped = new ExtendedException(sql, e);
throw wrapped;
}
}
}
Do you see the changes?
We now have better control of what will happened next. For example our UI code can now distinguish between existing items, no existing items and an exception occurring. A controller action might look like this
public ActionResult Index()
{
var results = new Service().GetModels();
if(results.Any())
{
return View(results);
}
return RedirectToAction("AddNew");
}
Exception handling can be placed in a global action filter that logs the error and redirects the user to an “error occurred” page.
Something we didn’t cover in this example was cleaning up components. This example does require it, but lets take a look at another example which cleans up after itself in the event of an exception.
public IEnumerable<Entity> GetEntities(string sql)
{
IDbCommand command = null;
IDataReader reader = null;
try
{
command = connection.CreateCommand();
command.CommandText = sql;
reader = command.ExecuteReader();
while(reader.Read())
{
yield return reader.ToEntity();
}
}
finally
{
if (reader != null)
{
reader.Dispose();
}
if(command != null)
{
command.Dispose();
}
}
}
Here we are disposing of our command and reader components within the finally block. Notice that we don’t have a catch statement, it’s not needed. Granted we could move the ExtendedSqlException into this block, but I wanted to stick with our original code sample.
One last thing to note. The .Net framework contains the keywork using which allows us to write more expressive code when disposing of components. we can rewrite the above block as
public IEnumerable<Entity> GetEntities(string sql)
{
using (var command = connection.CreateCommand())
{
command.CommandText = sql;
using (var reader = command.ExecuteReader())
{
while (reader.Read())
{
yield return reader.ToEntity();
}
}
}
}
Which is the exact same thing as our previous block, but the code is much more expressive and easier to read.
Exceptions are meant to break way from the current workflow and inform the user that some unexpected happened. It is not meant to control the workflow the system. Too often I have seen code like this:
public class Service
{
public IEnumerable<Entity> GetEntities()
{
try
{
var entities = repository.GetEntities("select * from table …");
return entities;
}
catch (Exception e)
{
Logger.Log(e);
return new Entity[0];
}
}
}
The problem is there is no difference between the repository simply not containing any entities and something going horribly wrong in the lower components. Handling the scenario were no entities are present in the repository is completely different than getting a SQL exception, or any exception for that matter.
In other words, if the database returns no entities, I may want to redirect the user to “add new” screen rather than display an a listing of not entities. However, if an exception was thrown I may want to inform the user something unexpected occurred, that the system administrators have been notified and they should log off of the system, until further notice.
However I cannot do that in this scenario because the calling code cannot distinguish between no entities and fatal operations.
This also means the developer must understand the result have potentially 2 meanings. 1. No data is present and 2. an exception may have occurred.
So how can we improve upon this code so we can return the expected results and still provide a positive user experience within the application itself? That will be the context for my next post.
There are many documented (and undocumented) nuances between browsers and how they process a request. Today I came across one that had me stumped for the better part of the day.
I have a bit of jquery that looks like this:
$.get(this.href, function (result) {
$(result).dialog();
});
with the assumption that result returns a single DOM element, typically a form element. This was working well until the following result occurred
<form>
<script type=”text/javascript”>/*code goes here*/</script>
</form>
in this scenario the result was in the correct format, but the browser interprets this as
<form></form>
<script type=”text/javascript”>/*code goes here*/</script>
This result will produce to dialog boxes. The one you expect and a second one where you only see a title bar. The second dialog has no content, but scripts don’t have a visual representation. I account for this anomaly I had to munge with the jquery script.
$.get(this.href, function (result) {
$(result).first().dialog().append($(result).last());
});
Hopefully this will all become a mute point later on. I would like to implement client side templating and keep server calls to json response, but we are not there yet.
Two weeks I parted ways with my previous employer. It wasn’t an easy decision as I had been there for 7 years and my department was tight. More family than co-workers. But it was time to move on.
After a 2 week hiatus I’m now part of the Solutions Practice at CEI America as an Associate Architect! Lots of changes with this move. To start I’m working for an IT company. Typically I have worked for non-technical entities within the IT department. Another big change is working with a team of developers! This is by far my favorite aspect of the new job. A majority of my career has been of a lone developer. Not any more. I have a team of talent to help and challenge me, and vice versa. And finally, the biggest change: ditching the commute in favor of a home office! Well it wasn’t really a choice, I wasn’t looking to relocate across the state, but it’s what made this possible.
My blog will continue to be my own with no direct ties to my new employer. I may also start blogging about other topics too, not just techie-geek-speak.
