# Would it make sense to roll back module definitions which error half-way?

**URL:** <https://discourse.julialang.org/t/would-it-make-sense-to-roll-back-module-definitions-which-error-half-way/105228>\
**Category:** Internals & Design\
**Tags:** error, module, exception, modules\
**Created:** [October 20, 2023, 11:25am UTC](https://discourse.julialang.org/t/would-it-make-sense-to-roll-back-module-definitions-which-error-half-way/105228 "2023-10-20T11:25:44Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [October 20, 2023, 11:25am UTC](https://discourse.julialang.org/t/would-it-make-sense-to-roll-back-module-definitions-which-error-half-way/105228/1 "2023-10-20T11:25:44Z")

</div>

Consider this:

```julia-repl
julia> module M
         const a = 1
         error("e")
         const b = 2
       end
ERROR: e
Stacktrace:
 [1] error(s::String)
   @ Base ./error.jl:35
 [2] top-level scope
   @ REPL[1]:3

julia> M.a
1

```

So `M` and `M.a` are defined, even though defining the module failed half-way. Is that not a bit ugly? I’m reminded of database transaction terminology, where one of the desirable and mandatory properties for a transaction in databases is _atomicity_:

> The “all or nothing” property. A transaction is an indivisible unit that is either performed in its entirety or is not performed at all.