• 7 Posts
  • 175 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle
  • They make valid points, and maybe it makes sense to always prefer them in their context.

    I don’t think exceptions always lead to better error handling and messages though. It depends on what you’re handling.

    A huge bin of exception is detailed and has a lot of info, but often lacks context and concise, obvious error messages. When you catch in outer code, and then have a “inaccessible resource” exception, it tells you nothing. You have to go through the stack trace and analyze which cases could be covered.

    If explicit errors don’t lead to good handling I don’t think you can expect good exception throwing either. Both solutions need adequate design and implementation to be good.

    Having a top-level (in their server context for one request or connection) that handles and discards one context while the program continues to run for others is certainly simple. Not having to propagate errors simplifies the code. But it also hides error states and possibilities across the entire stack between outer catch and deep possible throw.

    In my (C#) projects I typically make conscious decisions between error states and results and exceptional exceptions where basic assumptions or programming errors exist.







  • Kissaki@programming.devtoProgramming@programming.devCode Smells Catalog
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    edit-2
    11 days ago

    The items don’t seem concise and always clear. But seems like a good, inspiring resource for things to consider.

    If it is expected that a method might fail, then it should fail, either by throwing an Exception or, if not - it should return a special case None/Null type object of the desired class (following the Null Object Pattern), not null itself.

    I’ve never heard of evading null with a Null object. Seems like a bad idea to me. Maybe it could work in some language, but generally I would say prefer result typing. Introducing a result type wrapping or extending the result value type is complexity I would be very evasive to introduce if the language doesn’t already support result wrapper/state types.


  • It’s an operating system that demands more of you than does the commercial offerings from Microsoft and Apple.

    Does it?

    It’s different, but I imagine they’re not fundamentally different if you exclude established knowledge/already being used to something.

    Normal office use for non-techy people is launching apps, editing documents, and surfing the web. That doesn’t work much differently, not fundamentally different, and not fundamentally more difficult.













  • English source code is a universal language.

    I’ve never seen a need for localization beyond domain terminology. And I think it would be a huge detrimental.

    To implement it would be unnecessary significant complexity. Effort better spent elsewhere. And for programmers it’d be confusing. Think code snippets, mixing content, and the need for reserved word expansion or exclusive parsing scopes that would be even more complex and confusing.