# Unitful.jl without parametrizing types on units?

**URL:** https://discourse.julialang.org/t/unitful-jl-without-parametrizing-types-on-units/99869
**Category:** General Usage
**Tags:** question, unitful
**Created:** [June 5, 2023, 5:08am UTC](https://discourse.julialang.org/t/unitful-jl-without-parametrizing-types-on-units/99869 "2023-06-05T05:08:41Z")
**Posts on this page:** 1
**Showing post:** 17

<div class="post-metadata">

### Author: ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)
#### Post date: [June 6, 2023, 4:10pm UTC](https://discourse.julialang.org/t/unitful-jl-without-parametrizing-types-on-units/99869/17 "2023-06-06T16:10:39Z")

</div>

I don’t do much for errors. The one thing I’d note is that instead of `Unitful.DimensionError`, I return the quantity as normal and set the `(q::Quantity).valid` flag to `false`. This is to remain consistent with the theme of type stability. That’s it though; it’s a pretty lightweight package: only ~300 SLOC.

(`MethodError` will still occur if a method is not defined for the Quantity type.)

This error return inspired by [GitHub - JuliaPreludes/Try.jl: Zero-overhead and debuggable error handling](https://github.com/tkf/Try.jl). From the discussion on [Performance of hasmethod vs try-catch on MethodError](https://discourse.julialang.org/t/performance-of-hasmethod-vs-try-catch-on-methoderror/99827) it seems like `try-catch` on a `DimensionError` is bound to be slower than tracking an extra value for errors in calculation.

---

_[View the full topic](https://discourse.julialang.org/t/unitful-jl-without-parametrizing-types-on-units/99869)._
