robotlegs / robotlegs-framework

An ActionScript 3 application framework for Flash and Flex
https://robotlegs.tenderapp.com/
MIT License
967 stars 261 forks source link

Logger warn throws an error #166

Closed jakehilton closed 9 years ago

jakehilton commented 10 years ago

I wouldn't expect to have a logger warn throw an exception. It seems like a fatal or error should for sure.. but a simple warn seems overkill for that since in a debugger it halts execution.

The following code is the offender in src/robotlegs/bender/extensions/vigilance/VigilanceExtension.as:

public function log(source:Object, level:uint, timestamp:int, message:String, params:Array = null):void
        {
            if (level <= LogLevel.WARN)
            {
                throw new VigilantError(_messageParser.parseMessage(message, params));
            }
        }

I would suggest if it be lower than warn that it be thrown.. IE:

public function log(source:Object, level:uint, timestamp:int, message:String, params:Array = null):void
        {
            if (level < LogLevel.WARN)
            {
                throw new VigilantError(_messageParser.parseMessage(message, params));
            }
        }

Just curious what the rationale is with throwing an error when doing a simple warn?

Thanks, Jake

darscan commented 10 years ago

Hello @jakehilton

Yep, I can see how it might be surprising! Here's my rough rationale (/opinion/nonsense) :

The Vigilance Extension is installed by the default MVCS Bundle, and is there to help debug problems early on in the development cycle (and while learning the framework).

Halting execution and dropping you into the stack is handy because you can inspect the full state of your app with your favourite debugger/IDE. Drop down the stack a bit and you'll be at the exact place where the warning was raised, with access to the surrounding scope/environment. Early on in development there is no good reason to issue warnings that do not need to be dealt with. Later on things change.

Warnings are interesting things. They are little cries of help that can only be heard at runtime. They say things like: "Woah, that should NOT have happened! I can deal with it for now, but somebody really needs to look into it".

In a live environment you really want to know about stuff like that. You don't necessarily want the users to know about it, and you certainly don't want to hard-crash the app, so you make sure you've got a way to capture and analyse the warnings and notify the relevant people/systems.

During development you don't want such a system in place. It's easier to just halt, inspect, and fix problems as soon as they happen.

When you want to deploy your app or show it to other people, you need to create your own Bundle - one that doesn't include the Vigilance Extension and instead contains your own preferred method of dealing with warnings.

The MVCS Bundle is a quick way to get started, but once you get going you'll want to replace it with your own team/app/personal Bundle. For now, if you really wanted to, you could just copy the MVCS Bundle into your app, call it something else, delete the line that installs the Vigilance Extension, and deal with warnings later.